Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)

From: Avery Pennarun <apenwarr@gmail.com>
Date: Aug 28, 2009, 15:29 UTC
Message-ID: <32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com>
In-Reply-To: <m3ocq0km5m.fsf_-_@localhost.localdomain>

On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:

Show 7 quoted lines

> From what I understand (from what I have read, and browsed, and
> lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
> in very different way that in Git:
>
>  * the svn:mergeinfo is client-side property; if I understand
>   correctly this would help you in repeated merges, but not anyone
>   other

I don't believe there is such a thing as a "client-side property" in svn. I see someone said this on stackoverflow (http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent) but I'm pretty sure they were either mistaken or using a different definition of "client-side."

I think they probably meant that it's the client's responsibility to set the property correctly, not the server's, and if your client is too old any you do a merge, it'll forget to set svn:mergeinfo, causing confusion for everyone. There's discussion in the svn book (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but nothing implies that it's a non-replicated property. Indeed, I can see no particular reason that anyone would want it to be, for the reasons you specify.

Show 6 quoted lines

>  * svn:mergeinfo contains _per-file_ merge info, so it is much, much
>   more "chatty" than Git multiple parents.  This might be more
>   powerfull approach, in the same sense that more advanced merge
>   strategies that 3-way merge were more powerfull -- but 3-way merge
>   is best because it is simple (and either it is simple that 3-way
>   merge is enough, or complicated so manual intervention is required).

svn people really love their cherry-picks and want to keep track of which things get cherry picked from one branch to another. This is nice (at least for informational purposes) although they go through some probably-unnecessary contortions *after* doing this, including splitting a merge from "maint" into "master" into two sequential merges, if you've previously cherry-picked a commit from master into maint. The above svn book link describes this in a bit more detail.

I don't think that behaviour would be much help in any situation I've ever experienced, so I agree with your comment that 3-way merge is generally better.

Tracking cherry picks in git would be really nice *sometimes*, but it creates a tradeoff where you then have to slurp in huge amounts of history that you might not want. In svn, this tradeoff doesn't exist, since anything you cherry pick must have already existed on the server anyway, and can never go away.

>  * You have to explicitely enable using svn:mergeinfo in log and blame

Conversely, in git you can basically disable it using --first-parent, which is sometimes handy. (It's handiest if your team has a policy of always using --no-ff when merging into trunk, which makes git act a bit more like svn's merge tracking. I realize this is a bit heretical to suggest on the git list, but I appreciate that the option exists despite its heresy :))

Have fun,

Avery