[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: How to change paths on an external file without a full update --depth infinity?

From: <dlellis_at_rockwellcollins.com>
Date: Thu, 15 Aug 2013 16:09:22 -0700

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.