On Tue, Apr 17, 2012 at 11:52 AM, Andy Singleton <andy_at_assembla.com> wrote:
> On 4/17/2012 11:38 AM, Paul Burba wrote:
>>
>> On Mon, Apr 16, 2012 at 12:25 PM, Julian Foad<julian.foad_at_wandisco.com>
>> wrote:
>>>
>>> I have written out how I think a large part of the symmetric merge
>>> algorithm should go, in more detail. Review and other feedback would
>>> be welcome.
>>>
>>> We need to write out the algorithm in this level of detail and a
>>> little more detail, and then write several new functions for
>>> implementing parts of it. I had until recently been thinking that I
>>> would be able to re-work most of the existing functions to accomodate
>>> what we need, and I have made some improvements along the way, but
>>> that is proving too difficult. (I started making some notes in
>>> <http://wiki.apache.org/subversion/MergeCodeImprovements> about things
>>> that I think we should be looking to change in the existing merge
>>> code.)
>>>
>>> At this point I haven't included processing of subtree mergeinfo in
>>> the algorithm description, though I have that in mind too.
>>
>> Hi Julian,
>>
>> So what is your plan for dealing with subtree mergeinfo then?
>> Implement the following then try to deal with it? Or get agreement on
>> what you have here then try to add that on? I worry about proceeding
>> to far without considering how subtree mergeinfo will be handled,
>> since most of the difficulties with and subsequent improvements to
>> merge tracking since 1.5 related to subtree mergeinfo.
>>
>> And what about other merge "edge" cases, e.g. shallow merges, shallow
>> merge targets, merge targets with missing subtrees (due to switches or
>> authz restrictions). Just some things to keep in mind (FWIW the merge
>> test coverage is pretty thorough in these areas so breakage will be
>> obvious).
>>
>> Paul
>
>
> I don't think there should be any implementation of subtree merge in the new
> symmetric merge. The new merge will still be very useful, even if it halts
> with a message after finding subtree merginfo.
Hi Andy,
My understanding is that the --symmetric option will eventually go
away. If that is still the case, what happens to users who have
subtree mergeinfo in their repositories (e.g. ourselves!
svn.apache.org/repos/asf/subversion). Do merge tracking aware merges
just stop working for them? Do we add a new option that uses the
existing merge logic so they can continue to merge?
> Here are three arguments against subtree merge:
Do you mean subtree merges or merges to targets with subtree mergeinfo?
> 1) My interpretation of the issue log agrees with Paul's observation that a
> high proportion of bugs and implementation problems during the past four
> years have come from subtree merge. This is a waste of talent and is
> holding back progress in other areas.
FWIW pretty much all of these issues are fixed as of 1.7. OTOH it
certainly does complicate the symmetric merge work.
> 2) It is not clear that there is any algorithm (given current tracking data)
> that can correctly merge branches where subtrees are at different revisions.
Do you mean our merge target is at mixed-revisions or that the target
has subtrees with explicit mergeinfo such that different revision
ranges are are required for different subtrees (and/or the root of the
target)?
> Why beat your head against a brick wall?
> 3) It's apparently a bad idea for users to be maintaining subtree merges.
> The existing subversion documentation recommends against it.
Regardless, plenty of users have it now, we can't just ignore it or
hope it goes away.
> I think that the algorithm that Julian proposed for finding the latest
> synced revision will work when the merges are only going between A and B.
> This simplifies a lot of good workflows.
+1 to doing away with --reintegrate and the keep-alive-dance, I'm on
board with that goal.
> Would it make sense to add more
> information, such as the actual merge history, so that you would know about
> other merge routes?
I don't completely follow, what did you have in mind exactly?
Paul
> I think it would be required eventually. Merginfo
> does not contain very much information.
> As a first step, does it make sense get this working completely without
> cherrypicks? This will give us a easy-to-use merge which halts if it finds
> cherrypicks or subtree merginfo, and which could be confused if there are
> merges through a third branch. However, it will be a nice improvement of
> the typical case where you are moving things between trunk and a feature
> branch.
>
>
> --
> Andy Singleton
> Assembla
Received on 2012-04-17 18:20:13 CEST