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

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> 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.

>  * 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