> >> 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.
Received on 2013-08-16 01:10:34 CEST