On Fri, 28 Aug 2009, Avery Pennarun wrote: > On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html