Re: Merging in Subversion 1.5
On Fri, 28 Aug 2009, Avery Pennarun wrote:
> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
Show 10 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.
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.
Show 18 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.
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
Jakub Narebski <jnareb@gmail.com>