On Mon, Jul 11, 2011 at 11:51 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 07/11/2011 11:46 AM, Andy Singleton wrote:
>>
>> Many developers are moving from Subversion to other SCM systems that have
>> better merge capabilities. I have posted an article with a proposal to fix
>> this problem, here:
>>
>> http://blog.assembla.com/assemblablog/tabid/12618/bid/58122/It-s-Time-to-Fix-Subversion-Merge.aspx
>
> [...]
>
>> I think that we can build a newmerge prototype by stripping down the
>> existing merge to remove the subtree options, and moving to the extensible
>> merginfo format. It will be useful to get advice about this from experienced
>> team members.
>
> Your optimism is lovely (and welcome, even!), but I am not as convinced as
> you that the reason why Subversion's merge functionality is subpar is as
> superficial as the items you call out (and which are implied by your
> prototyping plan above).
>
> Very little (if anything) about your proposal touches on the *real*
> problems, such as Subversion's handling of moved/renamed objects, tree
> conflict detection/handling/resolution, changeset conflation caused by the
> fundamental diff+patch approach Subversion takes to merges rather than
> first-class changeset support), etc. These real problems with merging were
> documented many years before the merge tracking feature was ever conceived,
> and neither that feature nor its skin-deep-only warts you aim to address
> made a dent in solving those very real problems.
>
> I don't aim to discourage -- far from it! On the contrary, I want to
> encourage a deeper review of the situation. It's entirely possible that, in
> doing so, you will find solutions for the deeper core problems here, and
> obviously the Subversion community (devs and users alike) would love that!
>
> -- C-Mike
>
> [1] I'll grant that in your blog post, you at least acknowledge the tree
> changes problem and place great stock in your extensible merge tracking
> format toward some future solution.
Improving merge correctness, performance and ease is one of WANdisco's
priorities over the 1.8 release cycle. I don't know that anybody
knows what the ideal solution is here, but Andrew's ideas are at least
worth exploring.
We should probably consider having Andrew and his group do their work
on a branch in our repository.
[ None of this in any way disparages the work done by folks on the
current merge and merge tracking implementations. I know that Paul in
particular has done yeoman's work in maintaining that dark corner of
our code, and I have great respect for that. I hope we can improve on
those efforts, not throw them away. ]
-Hyrum
Received on 2011-07-12 15:41:09 CEST