incorrect merge result

[Burckhardt, Jacob P.]

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.