[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
incorrect merge result
From: |
Burckhardt, Jacob P. |
Subject: |
incorrect merge result |
Date: |
Tue, 12 Feb 2002 12:50:35 -0800 |
Heirler Stefan writes:
> Lines 967 and 968
>
> *LineNumber = charobj->in_line;
> *maxLineNumber = charobj->in_line; /* not support for this implementation
> */
>
> at the beginning of function
>
> (void) ignoreReject;
>
> in the merged file are not present in both versions of the file and
> should therefore be part of the conflict and not outside of the
> conflicting region of text.
Using your test case I reproduced a bug in cvs-1.11, but I disagree
that cvs should mark this as a conflict.
File modified_ipif_obj.c did not change that function at all with
respect to 1_19_ipif_obj.c. But file 1_22_ipif_obj.c did change it
with respect to 1_19_ipif_obj.c. Since only one file has changes in
this area of the file, then it should not be a conflict. Instead, the
merged file should have the version of this function that is in file
1_22_ipif_obj.c. But, cvs-1.11 shows the version from file
1_19_ipif_obj.c. So it is a bug in cvs-1.11, but it's a slightly
different bug than you thought.
I also tried your test case on cvs-1.11.1p1 and it worked correctly.
I.e., it did not mark this area of the file as a conflict. It put the
version from 1_22_ipif_obj.c into the merged result.
In this email, I attached the merged result from cvs-1.11.1p1, but I
used different filenames and version numbers when I tested, so the
conflict makers have these different names and numbers than
compared to your own repository.