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
Sorry, but I think this post is pretty hand-wavy in that it lacks much
substance or detail. It frames itself around the notion that merge is
the problem and that fixing the problem is as simple as making a new
command that does not allow the complex options of the old command,
but it ignores the fact that almost everywhere the proposal provides
some details it is describing what would have to be a totally new
product or redesign of core SVN.
> 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>”
SVN already has this.
>, and a cherrypick form “newmerge <fromsource> <specific changes>.
It also has this, although "specific changes" is pretty vague. So
hard to say for certain.
> 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,
You want to eliminate ranges? Then how do you propose to implement
cherry picks?
> “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.
These things definitely can make merge more complex and it probably
would have been good if we made some of the decisions back during 1.5
development, but most of the issues around them have been solved now.
So this actually gives SVN some fairly powerful merge capabilities.
In your blog post you talk about people coming from tools with
powerful merge but then propose a solution that removes the power?
How does having a new merge command change the fact that some users
might use the old merge command and create these kinds of merge issues
in your repository? Obviously you have to invent some kind of way for
the server to dictate the types of merge you want to support, in which
case you do not need a new command at all and the current merge
command could provide what you ask for as is. In other words, the
server could tell the current merge command not to allow these
options.
> * 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.
Changes have a global ID? This sounds like you are proposing a
product that does not exist?
> * 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.
Why get into this level of implementation detail here when everything
else is so vague. The current mergeinfo property handling has been
annoying, but that has been fixed in 1.7.
> 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.
There are two remaining problems in SVN merge:
1) The need for a --reintegrate option, and the limitations that come with it
2) The lack of support for automatically handling moved/renamed paths
Neither of these are failures in the merge code they are failures in
the core design of SVN. You are not going to be able to solve these
problems with a new merge command, you are going to need to a new
design for SVN or some major changes in current design. Again, once
that is done, there is no reason the current merge cannot take that
in.
I hope you are planning to devote some resources to this, I think that
would be great. And I look forward to seeing a prototype move
forward. I think you are approaching this wrong, but that should not
stop you and maybe some new ideas will come out of it. I would like
to see more details though and more of an acknowledgement of how the
core SVN design is to be addressed to solve these issues.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-07-11 18:10:24 CEST