It seems to me that your original post had two questions:
1) What is the difference between "diff+patch" and a "3-way merge", and
why is "3-way merge" considered better?
2) diff3 claims to operate on two files and a common ancestor. That's a
special case of the svn situation, which is 3 files descending from the
same common ancestor. Why is this not a problem?
The answer to 1) is pretty straight forward: both methods attempt to do
the same thing, but "3-way merge" has more information available when
applying the patch which allows it to be smarter about avoiding spurious
conflicts. We've had a couple of examples to demonstrate this, so I
won't belabour the point.
I don't think we've had an answer to question 2) yet, though. Here's my
gut feel on the situation.
I think the problem is that the documentation for diff3 is misleading.
AFICT, the whole "common ancestor" thing is just the common use case.
The actual algorithm merely requires some degree of relatedness between
the three texts so that hunks of difference and context can be
identified. diff3 doesn't really care WHAT the relationship exists
between mine, older, and yours. It would work fine if you tried to apply
the differences between mine and yours to older.
To me this implies that diff3 is adequate but not ideal for our
purposes. I think would be possible to design better plug-in merge tools
that take advantage of not only the similarity of the texts but also the
information about their exact relationships that svn has access to. Your
paper about patching a patch (I forget what you called the process)
would be one example. This underscores the need for the "Support for
plug-in client side diff programs" goal on the subversion home page, and
suggests that it needs to be extended to include plug-in client site
Colin Putney www.whistler.com
Information Systems (877) 932-0606
Whistler.com (604) 935-0035 x221
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:37:08 2006