On Dec 5, 2007 7:55 PM, David Glasser <glasser@davidglasser.net> wrote:
>
> 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.
Yeah, I kind of understood that (which is why I was surprised to get
the pushback in IRC). Your original spec said you would take the REV
of the WC and then make go to the URL, get is mergeinfo and make sure
it had been synched up to that revision. It seems like you could
easily turn this around. Go to the mergeinfo, find out what revision
it had been synched to, and then just make sure the WC was at least at
that revision.
I wonder once you go through this cycle once:
1) Create feature branch
2) Changes on feature branch
3) Synch with trunk
4) More change on feature branch
5) Synch with trunk
6) Merge back to trunk
Now, suppose you want to make more changes on feature branch. Can the
cycle just repeat? Does the user need to know that they should
probably delete branch + recreate it?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 6 02:03:39 2007