From: Jakub Narebski <jnareb@gmail.com>
Date: Fri, 28 Aug 2009 16:19:06 GMT
Subject: Re: Merging in Subversion 1.5
Message-ID: <200908281819.10135.jnareb@gmail.com>
In-Reply-To: <32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com>

On Fri, 28 Aug 2009, Avery Pennarun wrote:
> 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.

What about svn:ignore or svn:mimetype (IIRC) property?

> 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 I got this (wrong?) impression from there.

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

Errr... what I meant here that I have read (on some blog, but either
I didn't bookmark it, or I can't find the bookmark) that svn:mergeinfo
is not as simple as listing _revisions_ which are merged (i.e. either
all parents, or additional parent), but it lists per-file merge 
information, and can be quite large.
 
> >  * 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. [...]

In git-log.  But in git-blame?

-- 
Jakub Narebski
Poland