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.
--dave
--
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