Re: Merging bug (wrong conflicts)

[Jacob Burckhardt]

Karl Tomlinson writes:
> So I recommend as a test example for configuration 2) of
> http://www.mail-archive.com/bug-cvs%40gnu.org/msg00803.html
> 
> M:
> v
> s
> x
> m1
> m2
> m1
> x
> m2
> s
> v
> s
> m1
> x
> m2
> m1
> m2
> x
> s
> v
> 
> O:
> s
> x
> m1
> m2
> m1
> x
> m2
> s
> v
> s
> x
> m1
> x
> m2
> m1
> m2
> x
> s
> 
> Y:
> s
> m1
> m2
> s
> v
> s
> m1
> m2
> s
> 
> I tested this with diffutils diff3 version 2.7 and it produced conflicts.
> No conflicts with older as the common file.

I saw different results than you.  You said no conflicts with older as
common file, but I did get conflicts.  Maybe we used different
commands?  My command was:

cat YOURS | diff3 -E -am MINE OLDER -

That gave:

v
s
m1
m2
s
v
s
<<<<<<< MINE
m1
x
m2
=======
>>>>>>> -
m1
m2
s
v

But I think it is OK that it is in conflict.  Like you said, there is
often more than one equivalent diff and if all you have is the end
result of a person's edits then cvs doesn't necessarily know exactly
what part of the file he edited.  So cvs can't be expected to always
pick the diff which matched what the person did.  Below, I show one
reasonable interpretation of the changes (although there are other
reasonable interpretations).  Your original files did not have any
blank lines in it, but I have added blanks lines so I can show what I
think diff considers to be similar lines.  I made it so that similar
liens are on the same horizontal level so it makes it it easy to make
your eyes horizontally scan it.  Note that I run diff3 on your
original files with no blank lines.  I only add blank lines here as a
way to show how I think diff is matching things up:

R means result of merge.

M  O  Y  R
v        v            
s  s  s  s            
x  x                  
m1 m1 m1 m1           
m2 m2 m2 m2           
m1 m1                 
x  x                  
m2 m2                 
s  s  s  s            
v  v  v  v            
s  s  s  s            
   x                  
         <<<<<<< MINE 
m1 m1    m1           
x  x     x            
m2 m2    m2           
         =======      
         >>>>>>> -    
m1 m1 m1 m1           
m2 m2 m2 m2           
x  x                  
s  s  s  s            
v        v               

I think it did something reasonable.  Change M deleted 1 line with an
"x" on it, and change Y deleted that same line plus the 3 lines just
below.  Those 3 lines are shown contained in the conflict brackets.  I
think it is not a burden to make a human manually look at that and
decide what to do.  And there is a good chance that deleting all 4
lines is not the right thing to do.  So therefore cvs should not just
assume that is right.  As long as you pick the right section of the
conflict, it will work.  Where as with some of my other test cases, the
unpatched cvs has a conflict where there is obviously no conflict or
it loses one person's changes with no hint to the user that it did so.

So to summarize, I think you patch makes cvs handle this case
reasonably.  So far, I am satisfied with your patch the way it is.

However, I am still worried that you and I get different results with
the unpatched diff3.  Perhaps that indicates that I am not testing
some case I *should* be testing.  So please let me know if I ran diff3
wrong.

BTW, I have not yet tried out your other cases in your other e-mails.

> 
> The prepatch cvs analyze.c is slightly different to diffutils (in 
> shift_boundaries).
> I haven't tried it but suspect that the conflicts will most likely still 
> occur.