Mark Phippard wrote:
> 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?
My impression is that you are on a dangerous path:
You think very much in special cases (and its implementation details),
without having a (simple and flexible) scheme for addressing
the whole problem.
Basically all the time you try to work around the fundamental problem
that your current mergeinfo scheme has not enough information
about the merge history.
What about the common case of having multiple feature branches
and merging also between feature branches?
What about Mark's question?
What about merging bug fixes from some release branch
into a feature branch and trunk, but not into another
feature branch, and then merging the feature branches to trunk?
And so on.
BTW, the algorithm quoted in
http://svn.haxx.se/dev/archive-2007-12/0139.shtml
handles
svn switch -r THE-REV url://trunk
svn merge url://branch
and
svn switch url://trunk
svn merge url://branch
and also Mark's cycle scenario well automatically,
*without* treating these situations as special case.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 6 10:28:37 2007