On Mon, Jul 11, 2011 at 12:48:27PM -0400, Mark Phippard wrote:
> If you want to fix Subversion merge there are two issues that have to
> be addressed. If you are not addressing these issues you are just
> rearranging the deck chairs on the Titanic.
>
> 1. Cyclic merges (the reason we added --reintegrate).
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2837
>
> This is really a core design issue in SVN that is going to be hard to
> work around.
>
> kamesh explored some new merge algorithm ideas in:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2897
>
> He may or may not have been on the right track. The solution is just
> so complicated no one was able to really review it.
I believe that conflict-free cyclic merges are never going to work
in any version control system, in the general case.
I have no proper theory to back this up. I just have a hunch that
no algorithm exists to determine, during a cyclic merge, which part of
an incoming change was originally made on the branch which is now the
merge target, and how the incoming change needs to be tweaked in
order to guarantee a conflict-free merge, in the general case.
If someone knows about an algorithm for solving this problem
please let me know. I think the best you can do is using heuristics,
and there will always be cases where these fail miserably.
> 2. Subversion does not handle move/rename well (tree conflicts)
>
> This is not just a merge issue, update/switch are also impacted by
> this problem. I do not know what the current state of the art
> thinking is on this problem. Can we auto-resolve tree conflicts at
> some point? When this problem was first approached (before we came up
> with tree conflicts) it hit a brick wall where it seemed a new
> repository design was needed:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=898
>
> Fix these two problems without killing performance and we would have
> solved the problem.
We will be able to auto-resolve a lot of tree conflicts involving renames
within Subversion's existing model as soon as we can follow copy-history
both ways on the client and server.
There is an existing prototype implementation by Nico Schellingerhout
and Piet-Hein Peeters at http://trumerge.open.collab.net/ that backs
up this claim (and which is used in production by aforementioned authors).
I am looking forward to exploring how to auto-resolve tree-conflicts
involving client-side renames, maybe for 1.8. This is a small part of
the general problem, but should be easy to do with wc-ng.
I think we should take a close look at trumerge and try to bring as
much of its functionality as possible into Subversion's core.
This will likely require some server-side changes if we want to keep
performance up, but it will be well worth it.
The trumerge authors have also done useful theoretical work.
Nico once showed me a table of possible rename conflicts, and how he
decided to auto-resolve each on a case-by-case basis. This is very
valuable work we should build on.
In the meantime, if Andy has fresh ideas to bring to the table,
I'm all ears. I agree with Mark's and Mike's concerns about lack
of focus on the really hard problems. But I am also convinced that
there is still a lot of room for usability improvements in svn merge
even without tackling the underlying design issues.
Received on 2011-07-11 19:20:38 CEST