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.
