[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Symmetric Merge -- Algorithm

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 17 Apr 2012 14:45:34 -0400

On 04/17/2012 02:29 PM, Branko Čibej wrote:
> On 17.04.2012 18:40, Andy Singleton wrote:
>> 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.
>
> This sound suspiciously like Assembla's "newmerge" pitch all over again.
> I'll refrain from commenting on the technical merits of such an idea,
> only to note that I'll veto any solution that a) perpetuates the state
> where the users have to deal with two different merge algorithms, and/or
> b) creates a state of affairs when some forms of merges that are valid
> today become suddenly invalid, or broken, with a new release of Subversion.

I'd really prefer for this thread *not* to devolve into parties attempting
to read between the lines when the lines themselves are so fuzzily drawn.
Check your guns at the door, boys. :-)

Look, merge is a hard problem. Merge as defined within Subversion today is
a harder one, because those first few brave souls who took us down this path
weren't willing to settle for a solution that fell neatly out of a grad
school student's algorithmic scribblings yet was ill-suited to meet
real-world needs. While it is the case that many Subversion users have
complicated merge scenarios because of their own mishandling of a
complicated feature, it is also the case that many such users are in those
situations because their workflow so demanded it.

I'm all for simplifying what can be reasonably simplified, and applaud the
efforts made thus far toward that end. I also stand very much against
punishing existing users for upgrading to a newer Subversion with crippled
merge functionality. So I heartily encourage those with their minds attuned
to this area of the codebase to find ways to do what needs doin' with that
constraint in mind.

I'm not as convinced as Branko that introducing a new merge command is
necessarily evil. Certainly, if it creates confusion for users, that's a
problem: after all, this whole symmetric merge project is founded on the
idea that merge could/should be *less* confusing! But let's take the time
and invest the energy into exploring our options here. How can we give a
simpler merge command to those who need simpler merges while continuing to
provide a more advanced merge functionality to those that need it?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
Received on 2012-04-17 20:46:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.