Thread (11 messages) flat view 11 messages, 7 authors, 2016-06-15

Re: Merging in Subversion 1.5

From: Jakub Narebski <hidden>
Date: 2016-06-15 22:47:19

On Fri, 28 Aug 2009, Avery Pennarun wrote:
On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski[off-list ref] wrote:
quoted
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.
quoted
 * 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.
 
quoted
 * 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help