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

Re: About the whole-branch-merge branch

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-06 00:13:33 CET

On Dec 5, 2007 1:20 PM, Mark Phippard <markphip@gmail.com> wrote:
> Here is a typical work flow.
> I am working on my feature branch and periodically staying in synch
> with trunk by just running:
> svn merge
> svn ci
> I did not have to look at revisions, everything just worked itself
> out. Merge tracking at its best. At some point I feel I am ready to
> go back to trunk. I might do one last synch and then spend some doing
> testing again, or I might want to just go back to trunk and work out
> conflicts and do final tests in my trunk WC. In either case, I do not
> readily know the revision of trunk I last merged into the branch. You
> are saying that I have to now look at the merge history to determine
> this information, and then run:
> svn switch -r THE-REV url://trunk
> svn merge url://branch
> I think that I ought to be able to just:
> svn switch url://trunk
> svn merge url://branch

Here's the thing.

With the Subversion architecture as it is (specifically, the fact that
we lack a tree diff3), I do not believe that you can make "merge trunk
to branch" and "merge back to trunk" be the same operation.

This isn't a matter of UI, although that's not irrelevant. It's
fundamentally the case that bidirectional mass cherry-picking is a
very hard problem that to the best of my knowledge no open source
system gets right. For this sort of feature branch work, you really
need to invoke a different operation to come back.

Confusing? Sure. But still beats the conflict insanity of
bidirectional cherry-picking.


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 6 00:13:44 2007

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.