[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD
From:       Dmitry Potapov <dpotapov () gmail ! com>
Date:       2009-08-31 5:47:14
Message-ID: 20090831054714.GA6060 () dpotapov ! dyndns ! org
[Download RAW message or body]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]