#164 Odd behavior when "-O" and "-E" used together

[Tom Henderson]

Hi,

I'm seeing behavior that
appears odd to me when I combine "-E" and "-O" options.
Maybe this is really a new feature request, I'm not
sure. My apologies if you've heard about this already
-- wasn't obvious from the bug/RFE lists.

It appears that diff3 and xxdiff use different
algorithms to detect conflicts. Sometimes diff3 will
detect a conflict but "xxdiff -m" will correctly select
all regions. I'd like it if the "-E -O" combination
could detect that "xxdiff -m" had done things right,
write the merged output file (to the file specified via
"-M"), and exit without popping up a display window.
Or maybe this requires a new option, I'm not sure.

I've attached a tarfile that illustrates the problem.

>> diff3 -m work/mediation_integrate.F
old/mediation_integrate.F new/mediation_integrate.F > &
! mediation_integrate.F.merge_diff3 >> echo $status
1

Output file contains "spurious" conflicts found by diff3.

>> xxdiff -m -O -M mediation_integrate.F.merge_xxdiff
work/mediation_integrate.F old/mediation_integrate.F
new/mediation_integrate.F
echo $status
1

No remaining conflicts after xxdiff auto-merge. "Quit"
saves new file as expected. Non-zero status is returned.

xxdiff -E -m -O -M mediation_integrate.F.merge_xxdiff_E
work/mediation_integrate.F old/mediation_integrate.F
new/mediation_integrate.F
echo $status
1

Exits quietly but does NOT save results in output file
even though xxdiff auto-merge found no conflicts! This
is the behavior I'd like to see changed.

Does this require a fix or new feature? Or have I
missed some feature that already exists?

I'm using 2.9.2. I've attached a tarfile in case you
want to try and duplicate my reults.

Also, I've got a Ruby script that I believe does what
xxdiff-patch aspires to do. I've been using it for a
couple of years now. So far just a handful of users so
there's plenty of room for improvement. If you're
interested, see
http://box.mmm.ucar.edu/individual/hender/difftree-0.2.5.tar.gz

xxdiff is great! I've been using it for years.

Thanks!

Tom
hender@ucar.edu

[Tom Henderson]

gzipped tarfile

[Tom Henderson]

Logged In: YES
user_id=1205632

Oops. Forgot to tell you I'm running on Fedora Core 2:

>> uname -a
Linux loquat 2.6.10 #1 Mon Jan 3 09:36:44 MST 2005 i686 i686
i386 GNU/Linux

[Martin Blais]

Logged In: YES
user_id=10996

Hmmm this is interesting.

In your example, the output of diff3 are not "conflicts"
per-see, but rather an "ed" script file to make the MINE
file into the merged output. xxdiff merge will "accept"
changes in a 3-way merge if they are DELETE or INSERT hunks.
To understand this very clearly, I suggest that you
download the source distribution, and try this

cd xxdiff/src
xxdiff mine older yours

And then

xxdiff -m mine older yours

This should give you a very clear good idea of how the
automatically merging of the files works (mine/older/yours
contain all the possible combinations of changes). The idea
is that for merging, a 3-way diff assumes that the middle
file is an ancestor for both the leftmost and rightmost
file, and that INSERTs and DELETEs on the left and right
files are accepted trivially, and anything else is a conflict.

But xxdiff and "diff3 -m" do not use different algorithms
AFAIK. "diff3 -m" outputs an ed script that looks like
conflicts, but they're not.

Now, about the second item: you would like to use xxdiff's
output for automatic merging, and I think it's fair to do
that! It is true that in the case where the user does not
interact because there are no conflicts, right now, the
merged file is not written out. I should really make that
happen, it would indeed make more sense.

In the meantime, another approach -- which I implicitly
assumed all along -- would be for the calling script to
check if there are merge conflicts. SCM systems such as CVS
or Subversion or ClearCase do that for you, so that has
never really been a problem. The problem you have in your
case is that "diff3 -m" does not return a meaningful code to
help you find out if there are merge conflicts: its output
with "-m" is to return an ed script to edit the MINE file,
and if there are commands to be run (what you called
conflicts in your description) the return status outputs
that. So there is no easy way with diff/diff3 to obtain a
flag to know whether the changes imply a conflict or not.

Therefore, I really need to output the merged file when the
--exit-if-no-conflicts and --merged-filename options are
given, because this would solve the problem where the user
needs to figure out if there are merged conflicts. This
would be useful.

Thanks for the heads up, this will be on the todo list for
the next release.

cheers,

[Tom Henderson]

Logged In: YES
user_id=1205632

Thanks for the clarification! Unfortunately, I often must
use my xxdiff-based compare-merge-scripts on checked-out
copies where folks have swapped subdirectories around,
screwing up the CVS bits. Or on code someone got from a
release tarfile with all the CVS stuff ripped out. Or on
code from two different CVS repositories. Or to compare
checked out copies from CVS and Subversion. Or ... It's a
long story...

I'll be happy to beta-test the new behavior if you like...