Carlton,
How SVN performs a merge was a puzzle to me too, not long ago.
I thought that the process would need to be "completing the diamond" in a 3-way difference (diff3). That is, given a file <source-0> and two modified versions <source-1> and <source-2>, form <source-3> with both sets of modifications. That is, the difference <diff-3/0> between <source-3> and <source-0> should be the combination of <diff-1/0> and <diff-2/0>.
However, SVN merge does not work in this way. Rather, it is a diff/patch process. The patch program, given <source-0> and <diff-1/0> should produce exactly <source-1>. To do a "merge", a difference such as <diff-1/0> is patched over a different input file such as <source-2>. Now the delta information in the diff file <diff-1/0> will not correspond exactly to <source-2>, and thus the patch program must do some work to try to "synchronise" the difference with the source. I imagine that this must be heuristically driven.
This is why you're not seeing a difference in the content of the merged files. Patch does not use the history of its input source.
Of course, SVN's merge does more than patch, as SVN understands something about trees of files whereas patch does not.
As something of an aside, I don't know whether you should expect that the result of patching <diff-2/0> over <source-1> should be the same as that of patching <diff-1/0> over <source-2>. I would have thought that in general these would be different, but I don't know for sure.
The reason that SVN's merge is based on diff/patch rather than diff3 becomes clear when you start to think about the sorts of things that happen to source files in the development process. Often, a partial merge from, say, a branch to the trunk may already have happened before a final merge from the branch to the trunk. Often, too, before a merge from branch to trunk, there has already been some selective merging from the trunk into the branch. Alternatively, a "cherry-picking" merge from branch to trunk might be required. Diff3 can cope with none of these circumstances, as there is no longer a common ancestor.
To deal with these sorts of situations, something like a "diff4" is required to "complete the pentagon". I don't know whether such a thing might be in the pipeline.
By the way, SVN does not currently *track* merges. However, the marvellous SVN developers are actively working on this at the moment. From the design documentation, it would seem to be a long and complex series of tasks!
[I look forward to reading anyone else's comments regarding the "--ignore-ancestry". I'm afraid I'm not in a position to answer that myself yet.]
I hope these comments are of some help to you, even if they don't answer your questions directly.
Rob.
-----Original Message-----
From: Brown, Carlton [mailto:Carlton.Brown@BellSouth.com]
Sent: 04 December 2006 18:29
To: users@subversion.tigris.org
Subject: Ancestry for dummies
I noted the results, then repeated the tests with one change: Instead of re-baselining with "svn copy", I performed an export of R1.0 and imported it to R2.0. So they were still identical, yet all the ancestry had been discarded in R2.0
_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.
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.
Received on Tue Dec 5 10:54:24 2006