On Mon, Aug 31, 2009 at 07:41:56AM +1200, Sam Vilain wrote: > On Fri, 2009-08-28 at 08:12 -0700, Jakub Narebski wrote: > > > Also IIRC there is warning (well, at least there was in Subversion 1.5 > > release notes) that merge tracking doesn't work entirely correctly in > > the face of criss-cross merges (multiple merge bases) and renaming > > (although I do hope that they fixed problem with silent corruption if > > there is rename during merge). > > Not sure about that one. I also heard - unconfirmed - that things start > to go awry if you start branching off branches and merging around the > place. But if that happens it's likely a bug rather than a design flaw > (I think). Some of the initial issues that existed in SVN 1.5.0 have been resolved, but some others remain. Here is one bug report related to merge: http://subversion.tigris.org/issues/show_bug.cgi?id=2897 It was reported two years ago, but the problem is still not fixed. And there is a few others (some of them even older but even with less prospect of being fixed any time soon): http://subversion.tigris.org/issues/show_bug.cgi?id=2837 http://subversion.tigris.org/issues/show_bug.cgi?id=2898 http://subversion.tigris.org/issues/show_bug.cgi?id=3056 http://subversion.tigris.org/issues/show_bug.cgi?id=3157 I don't think they would exist for long if they were ease to fix. Merge in Subversion is essence automatic cherry-picking, and it is not easy to implement that in the way it would be reasonably fast and work correctly in a general case. Darcs is probably the best when it comes to cherry-picking but clearly it is not a speed demon. In case of Subversion, the problem is worse, because it has to make decision on a per file basis rather than operate each patch as a unit. So, it is even more difficult to implement that correctly and efficiently. What you can do relatively simple is to handle a of one directional merge, and that was the primary design goal of Subversion merge tracking feature. Here is what Daniel Berlin wrote about it: <<< The initial merge tracking implementation was not meant to handle repeated bidirectional merging, at least, as designed. It was designed to allow cherry picks, and mainly for maintaining feature branches that were mostly one way merges, with the very occasional merge in the other direction and then branch death :). For these cases, it works out fine. For more complex cyclical merge patterns, you really can't use what we've got. Trying to work around these cases, or build algorithms that handle them, is just going to lead you into 20 years of edge cases that made people come up with changeset dags in the first place. >>> Source: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=892215 So, I do not think that SVN merge will ever work correctly for those edge cases. But even if Subversion learns how to handle all those complex cases correctly, it will still come with some surprises. One of the main advantage of the simple 3-way merge is that it is easy to understand and it makes the right thing most of time. Linus provided a really good explanation of it here: http://thread.gmane.org/gmane.comp.version-control.git/60457/focus=60644 Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html