On Fri, 2002-02-15 at 00:08, Karl Fogel wrote:
> Above, Greg implies that what CVS does is good (presumably 3-way) and
> what we're going to do is bad (presumably not 3-way), while others
> have implied that "cvs merge" is not a good model because it is not
> 3-way :-).
I don't recall anyone having said that CVS's merge is not 3-way.
Certainly, "cvs update -j rev1 -j rev2 foo" winds up doing a (more or
less) "diff3 -Em foo /tmp/rev1tempfile /tmp/rev2tempfile" to produce the
conflict-markered file. I know this because I recently tracked down a
bug in diff3 which was causing my CVS merges to flag spurious conflicts.
> CVS's merge takes the differences between two revisions of a file F,
> and applies them to some third revision of F.
That's a deceptive statement. That's what it imply by its output, but
under the covers CVS does a three-way merge using diff3.
Whether diff3 is a good implementation of a three-way merge is another
question. When you run "diff3 A B C", what it does is invoke "diff A C"
and "diff B C" to produce two different patches; then it wanders down
the list of hunks in those two patches to make a combined patch.
Unfortunately, the hunk-wandering algorithm is rather sensitive to the
nature of the patches, so it can mark conflicts where none exist. In
the current released version of GNU diffutils, there are files for which
"diff A A B" can actually produce conflicts, because it invokes the two
diff commands with different heuristic options and winds up trying to
merge two equivalent-but-differently-formed patches. (See
http://web.mit.edu/ghudson/info/diff3-bug.) Fortunately, this
particular problem was already fixed in the latest interim release when
I reported it. I still bet that one could do a better job by not
relying on "diff".
(It's also a little weird that diff3 uses the "newer" file as the common
file; you'd think it would want to use the "older" file as the common
base, since there is no particular relationship between "mine" and
"newer".)
---------------------------------------------------------------------
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