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

Re: Merge-tracking question: what happens with cross-branch commits?

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-08-03 22:20:43 CEST

On 8/3/06, Daniel Rall <dlr@collab.net> wrote:
> On Thu, 03 Aug 2006, Malcolm Rowe wrote:
> > On Thu, Aug 03, 2006 at 10:25:55AM -0700, dlr@tigris.org wrote:
> > > New Revision: 20951
> > >
> > > Modified:
> > > branches/1.4.x/subversion/include/svn_wc.h
> > > trunk/subversion/include/svn_wc.h
> > >
> >
> > So I guess I'm curious - what should a merge tracking solution do with
> > something like that, in general?
> This was a manual change and commit made to both branches (e.g. no
> merge), so we wouldn't be modifying any merge history here.
> > What do svnmerge and the current merge-tracking branch do?
> If the changes had been brought about by a merge into the WC, the
> current merge-tracking branch would've added to the merge history for
> both svn_wc.h paths during the merge, and persisted that to the repos
> upon commit.
> If this had been a merge, and all tags and branches our repository
> contained a similar merge (highly improbable, in this case), the merge
> info would be "elided" into the repository root ("/").
> svnmerge.py allows for tracking merge info only at a tree/branch root,
> meaning that merges for which you want to retain merge history must be
> whole branch (tree) merges (sub-tree merges aren't supported).
> Clear as mud, right? :-)

So if I tried to merge the portion of the commit from trunk into
1.4.x, the merge tracking code would have no way to determine that it
shouldn't be done, and a conflict would likely occur, right? So we
should just tell people not to do stuff like that if they want merge
tracking to be any good ;-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 3 22:24:01 2006

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

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