On Dec 5, 2007 4:38 PM, Mark Phippard <markphip@gmail.com> wrote:
>
> 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.
Yes, it's being converted into a 2-URL merge, but the 2-URL merge is
calculated based on the rev of the wc.
On the other hand, I have no problem with people taking things that
are currently errors (SVN_ERR_CLIENT_NOT_READY_TO_MERGE) and making
them be supported, as long as it's safe. I figure, start with
something conservative, relax restrictions later.
--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 01:56:17 2007