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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-07-11 18:52:29 CEST