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

From: Jakub Narebski <jnareb@gmail.com>
Date: Aug 28, 2009, 15:12 UTC
Message-ID: <m3ocq0km5m.fsf_-_@localhost.localdomain>
In-Reply-To: <4A97E1B1.7090107@gmx.de>

Matthias Andree <matthias.andree@gmx.de> writes:

Show 19 quoted lines

> Matthieu Moy schrieb:
>> seanh <seanh.nospam@gmail.com> writes:
>> 
>>> 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