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:
>> 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
>  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
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. ]
Received on 2011-07-12 15:41:09 CEST