Rob Hubbard wrote:
> 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.
I am not a subversion developer but I can talk from the user
perspective.
> 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)
> ^ ^
> / \
> / \
> (T@200) (B@210)
> ^ ^
> \ /
> \ /
> (T@10=B@11)
>
> where (M) is the result of the merge.
Nice picture. Yes. Okay so far.
> I can see that either diff3 or diff/patch could produce the required
> result.
You need to say something about how the merge was performed. Such as
this:
svn diff -r101:210 $URL/branch
svn merge -r101:210 $URL/branch .
At that point I think in your debate it would say that it is a
diff/patch style of operation.
> But now suppose that further development occurs on both (T) and (B)
> and a further merge is required:
>
> (M)
> ^ ^
> / \
> / \
> (T@300) (B@333)
> ^ ^
> | |
> | |
> (T@200)<--->(B@210)
>
> 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.
Search the web for criss-cross merge and you will find discussion of
this problem.
> 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?
I don't know what it does under the hood. But my user experience is
that it is a diff/patch behavior. Take that obversation with caution.
I am probably wrong.
Again, to do the merge today's best practice is to record the
revisions for the merge in the log history. (Some will suggest the
svnmerge script, which essentially does the same thing for the
purposes of this discussion.)
svn diff -r210:300 $URL/branch
svn merge -r210:300 $URL/branch .
> Perhaps it can't do the latter, as only one base point is supplied
> on the merge command.
I don't believe you said what your merge command was so we can only
guess here.
> The SVN documentation hints that the process is of the diff/patch-style:
> "But svn merge has special abilities that surpass the patch program."
> but I don't think it's stated definitively one way or the other.
Subversion has some capability to handle renamed files. Using classic
diff and patch renamed files can only be deleted entirely at the old
location (a somewhat problematic operation) and created entirely at
the new location. That means history does not follow the file. But
if you use 'svn move' (and also 'svn copy') then subversion history
will track the file.
> This email and any files transmitted with it are confidential and
> may be legally privileged. It is intended solely for the use of the
> individual or entity to whom it is addressed. If you have received
> this in error, please contact the sender and delete the material
> immediately. Whilst this email has been swept for viruses, you
> should carry out your own virus check before opening any
> attachment. Celoxica Ltd accepts no liability for any loss or
> damage which may be caused by software viruses or interception
> or interruption of this email.
Wow that is a long and annoying disclaimer. And of course without any
value. Many people on the 'net will not answer posts which include
those. Consider using a different email account that does not force
these inclusions. Many such free accounts are available.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Aug 19 20:54:55 2006