Colin Putney <cputney@whistler.net> writes:
> 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.
Yes, absolutely. While I had an intuition as to why 3-way merge works
better here, I now understand it much more thoroughly. Part of the
problem was that I was looking for some huge, world-shaking difference
between 3-way and regular, and it turns out to be only a mild
difference -- an improvement, sure, but not like a whole new world of
merge success or anything. :-)
> 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.
Not even -- at least for me, it's been by far the least common case in
CVS merges, and I expect that will be true in Subversion as well,
since the tasks are basically the same. At most the common ancestor
is involved in the first merge to a given line, and after that it's
not involved. (One could call the left-side source of the merged
range a "common ancestor" each time, in a sense, if one always merges
*all* unmerged changes from the branch line the same target line, and
plans to continue doing so, but that's often not the case, and even
then it wouldn't be *the* common ancestor, it would just be one of
many "ancestors" to the head of the target line.)
Completely agree that the diff3 documentation is misleading, am
tempted to put it even more strongly than that. :-)
> 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.
Amen.
> 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 merge programs.
Yes, completely agree. Really perfect merging is much more
sophisticated than either diff+patch or diff3, and is non-trivial to
implement. Giving clients plug-in options is part of it (we'll have
to supply that fourth file -- the true common ancestor -- for them,
too!)
The paper is www/variance-adjusted-patching.html, by the way. It
probably suffers from making up terminology for things that already
had accepted words, but the meaning is the same anyway.
I don't think we're aiming for perfect merging right now. We just
need to be as good as CVS, and that means diff3 with three files, no
one of which is necessarily a common ancestor.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006