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. _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
