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

Matthias Andree [off-list ref] writes:

Matthieu Moy schrieb:

quoted

seanh [off-list ref] writes:

quoted

In response to Matthieu and Paolo, I'm not sure I understand the git 
internals involved in the discussion around merge --squash, I had a 
feeling this would produce a 'merge' that git in some sense would 'not 
know about',

Yes, that's it. Git does a merge, and immediately forgets it was a
merge. The consequence is when you merge again later, Git will not be
able to use the merge information to be clever about merging. Somehow,
Git will be as bad as SVN for merging if you don't know what you're
doing ;-).

To be fair, SVN versions 1.5 and newer can track merges. If the
repository predates 1.5, it has to be updated on the server side
(see the release notes for details). It just tracks which revisions
have been merged and which not, for further details, see the svn
book. (http://svnbook.red-bean.com/ IIRC)

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

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

 * You have to explicitely enable using svn:mergeinfo in log and blame

 * The command to merge trunk into branch is different from command to
   merge branch into trunk.

Also IIRC there is warning (well, at least there was in Subversion 1.5
release notes) that merge tracking doesn't work entirely correctly in
the face of criss-cross merges (multiple merge bases) and renaming
(although I do hope that they fixed problem with silent corruption if
there is rename during merge).

-- 
Jakub Narebski

Git User's Survey 2009: http://tinyurl.com/GitSurvey2009