It sounds like there is a clear choice for the first release of
Julian's Symmetric Merge project:
1) Add "symmerge" as a new command and leave the existing merge in place,
2) or try to replace the existing merge in one shot for all existing users.
If you asked me to try to replace all of the options and behaviors in
the existing merge, I would say that it is a daunting task that will
create delays. I would never take that as a deliverable for a agile
project. I would build a new merge command that handles as much as
possible of the workflow that we are trying to fix - sync and keepalive
for trunk and feature branches. I would have it halt politely if it
found a case it didn't like, and I would definitely include subtree
merginfo and mixed revisions in cases that I don't like. Then, I would
exploit the new merge to implement modern code review workflows -
including a replacement for the emailed patches on this list.
I would also use the new merge command as a documented template for
anyone who wanted to implement a different merge algorithm, and I would
open it up for contributions with some bounty rewards. You can't do
that if you are trying to cram everything into one merge command.
On 4/17/2012 12:19 PM, Paul Burba wrote:
> 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
--
Andy Singleton
Founder/CEO, Assembla Online: http://www.assembla.com
Phone: 781-328-2241
Skype: andysingleton
Received on 2012-04-17 18:41:18 CEST