bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging bug (wrong conflicts)


From: Karl Tomlinson
Subject: Re: Merging bug (wrong conflicts)
Date: Fri, 09 Feb 2001 11:22:00 +1300

"Derek R. Price" wrote:
> 
> > Karl, do you know what, specifically, was causing the merging problems?
> I can't come up with a minimal test case based on the message and comments in
> your patch.
> 
> I'm thinking that the eight cases Jacob has might all be examples of only a
> few or even one error case...  Is it possible to pare those down into one or a
> few simple tests?
> 

There are two things that I think could be tested.  The first should definitely 
be tested.  The second is less important.

1) That cvs is making a reasonable effort to guess the intended changes between 
each version which I believe is dependent on using the ancestor file as the 
common file for the 2 2-way diffs.

The files in diff-bug.tar.gz at

http://www.mail-archive.com/bug-cvs%40gnu.org/msg00429.html

are very simple and test this well but don't look much like files you'd expect 
to see under cvs.  I suspect Ingolf's example at

http://www.mail-archive.com/bug-cvs%40gnu.org/msg00548.html

may also test the same thing but I haven't actually looked at this and the 
files are somewhat larger.

2) That the 2 2-ways in diff3 produce the same output when they should.  This 
has caused problems in the past when the two non-common files are the same.  
These files used to be MINE and OLDER so the problem would occur sometimes when 
merging a change into an unmodified copy of a working file.  See Kevin's bug 
report

http://www.mail-archive.com/bug-cvs%40gnu.org/msg00288.html

With the patch, OLDER is the common file, so the potential problem could occur 
if the same change was on the branch as on the trunk.  i.e. the changes have 
already been merged in.  So a test might have testcase0-1.1 of Kevin's problem 
on the trunk, testcase0-1.1.2.2 on the branch, then merge the branch changes 
into the working copy twice.  I don't think the current standard version of cvs 
would have any problem with this.

My patch avoids this problem by using the same --horizon-lines arg for each 
call to diff, which Kevin also recommends.

The problem would only occur if the differences between versions were 
complicated enough so that there was more than one possible diff output.  All 
the examples of this problem I have seen have been quite large files, and the 
problem goes away on trying to reduce the size of the files.

Sorry, I don't have time now to assemble tests into a shell script.

Karl.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]