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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
