[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.
- Re: Merging bug (wrong conflicts), Jacob Burckhardt, 2001/02/07
- Re: Merging bug (wrong conflicts), Karl Tomlinson, 2001/02/07
- Re: Merging bug (wrong conflicts), Derek R. Price, 2001/02/08
- Re: Merging bug (wrong conflicts),
Karl Tomlinson <=
- Re: Merging bug (wrong conflicts), Jacob Burckhardt, 2001/02/08
- Re: Merging bug (wrong conflicts), Derek R. Price, 2001/02/16
- Re: Merging bug (wrong conflicts), Jacob Burckhardt, 2001/02/16
- Re: Merging bug (wrong conflicts), Derek R. Price, 2001/02/16
- Re: Merging bug (wrong conflicts), Karl Tomlinson, 2001/02/18
- Re: Merging bug (wrong conflicts), Karl Tomlinson, 2001/02/20
- Re: Merging bug (wrong conflicts), Karl Tomlinson, 2001/02/20
- Re: Merging bug (wrong conflicts), Karl Tomlinson, 2001/02/20
- Re: Merging bug (wrong conflicts), Jacob Burckhardt, 2001/02/21
- Re: Merging bug (wrong conflicts), Karl Tomlinson, 2001/02/21