On Mon, Jul 11, 2011 at 11:46 AM, Andy Singleton <andy_at_assembla.com> 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
>
> SUMMARY
> I propose to add a “newmerge” command, which will be compatible with
> existing svn servers and clients. It will be different from the existing
> merge command in the following ways:
>
> * It has a simple form “newmerge <from source>”, and a cherrypick form
> “newmerge <fromsource> <specific changes>. This pulls new changes from the
> source into the working copy, and merges them as automatically as possible.
> Changes can travel through multiple branches or repositories. The merge
> should work the same way, and work reliably, from branch to trunk, from
> branch to branch, or from trunk to branch.
>
> * We eliminate instructions like merge ranges, “reintegrate”, and “depth”.
> They add complexity and opportunities for human error.
>
> * It does not support subtree merges, merges to mixed working copies, or
> subtree/file merginfo. I think those cases cause a lot of complexity and are
> usually unwise. If you want to work on a subtree, then you can branch or
> clone the subtree and merge it back to the complete tree.
>
> * It can merge from foreign repositories, and track changes as they move
> through foreign repositories (eg clones). This is a common case in modern
> workflows. Changes have a global ID.
>
> * It will track mergeinfo (“merge_history”) in a versioned file that is
> committed into the branch. We want to have room to save any information that
> we need. It will have an extensible data structure, so that we can
> continuously improve this type of merge.
>
> 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.
Hi Andy,
I don't have a lot to add to what Stefan and Mark have already said,
but I do have a question:
Can't much of what you desire be achieved simply through policy, e.g.
merges are only done at the branch root level, no shallow depth
merges, no mixed-rev merge targets (already prevented by default in
1.7)? Or is it that you want these policies enforced?
One thing you can do that will help regardless of whether we go in the
direction you propose or not: Submit some new test patches. A few
well written tests that clearly demonstrate where the current design
falls down will help the rest of us understand what it is you are
trying to accomplish (and might get some parts of what you desire
fixed within the current design).
Paul
Received on 2011-07-11 18:34:34 CEST