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 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.
Founder/CEO, Assembla: http://www.assembla.com
Received on 2011-07-11 17:46:54 CEST