[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-12-06 01:38:43 CET

On Dec 5, 2007 6:13 PM, David Glasser <glasser@davidglasser.net> wrote:
> 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.

But, I thought in the second case (coming back to trunk) we would be
converting this into a 2-URL merge internally? I thought this was
essentially just syntactic sugar? My point is that the properly
crafter 2-URL merge would work fine in the situation I outlined, so as
long as we can programmatically determine the right options, we could
do the same. I thought that is basically what your proposal was also
saying? I just want to relax (slightly) the WC revision requirement
so that it is a little easier for someone to take advantage of this.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 6 01:38:53 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.