subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlel...@rockwellcollins.com
Subject Re: How to change paths on an external file without a full update --depth infinity?
Date Thu, 15 Aug 2013 23:09:22 GMT
> >> The commit won't complete you'll get an out of date error.
> >
> > That's right, isn't it.  It'd be no different than two folks trying to
> > commit the same file around the same time, right (one would get an out 
of
> > date error)?
> 
> Right, but when working on the trunk explicitly you'd expect to update
> to accept others' changes often, or to branch to preserve and isolate
> your differences.   I don't see how either quite matches a model where
> changes might be made based on multiple differing back-rev pinned
> externals.   What happens if two projects don't want to accept each
> others' changes and need to commit their own?  In a more typical
> scenario they would be working on branch copies that could diverge,
> but I think you lose that by forcing a canonical path for development
> (as a tradeoff for knowing where the 'new' work is...).
> 
If a project doesn't want to accept a change, they "fork" to a new 
"history".  The tool does this with a svn cp <old_pedigree/foo.c> 
<new_pedigree/foo.c> and an update to the svn:externals property.  They 
now lose sight of what the other project commits after that fork though. 
The backend of where the file is stored and how is masked by the tool. 
<pedigree> is essentially implemented as a folder.  To the developer, they 
may know that their file is really a file external, but they don't treat 
it really any different from a normal file until it comes time to "fork". 
I try to differentiate "forking" as a pedigree/history from branching and 
the like. 

This system is essentially an implementation of Rational's CMVC history 
feature.

Mime
View raw message