Curious about SVN Merge: diff3 or patch?
From: Rob Hubbard <Rob.Hubbard_at_celoxica.com>
Date: 2006-08-15 14:53:06 CEST
Hello,
I would like to understand better the "merge" process. In particular, I would like to know whether an svn merge is effectively a diff3, or a diff/patch process, or something else, more complex.
Suppose the trunk at revision 100 ("T@100") is branched to a new branch (B), so that B@101=T@100. Suppose that later, following development along both lines, B@210 is to be merged back to T@200 (or conversely). In this case, the merge diamond would be:
(M)
where (M) is the result of the merge.
I can see that either diff3 or diff/patch could produce the required result.
But now suppose that further development occurs on both (T) and (B) and a further merge is required:
(M)
It seems to me that the problem is no longer of a diamond shape, as the branch and trunk deltas are not from a common (or equivalent) ancestor. This is no longer "3-way", but "4-way" (as there are 4 files to consider, rather than 3). So, does SVN do a diff/patch (with patch using heuristics to synchronise), or does SVN understand the delta between the two base nodes, and do something more complex?
Perhaps it can't do the latter, as only one base point is supplied on the merge command.
The SVN documentation hints that the process is of the diff/patch-style:
If it's a diff/patch-style algorithm, then it may make a difference to the ease with which conflicts may be resolved whether you do this:
Is there any general guidance available on these matters, beyond the SVN book <http://svnbook.red-bean.com/>?
Many thanks in advance,
Rob.
_____________________________________________________________________
This email and any files transmitted with it are confidential and
---------------------------------------------------------------------
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.