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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand