Actually, I was able to reproduce the issue. It's not user error as there were not conflicts checked into CVS before the merge.
Executing the same steps and only changing the client version produces two different results. Conflicts exist in the sandbox but not in the repository with the 1.11.21 client, there's no notification about the conflicts when checking in the merged files, but the conflicts are never committed. The files with conflicts remain in the pre-merge state in the repository. Actually, the first time I ran into the problem I was attempting a fresh reproduction of an issue that a co-worker experienced and I wasn't expecting to be able to reproduce the problem, but did. -Chris -----Original Message----- From: Jim Hyslop [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 2:39 PM To: Steve McIntyre Cc: Jensen, Chris; [email protected] Subject: Re: Merge issue using client 1.11.21 and server 1.11.17 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve McIntyre wrote: > On Fri, Jun 02, 2006 at 03:18:55PM -0400, Jim Hyslop wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Jensen, Chris wrote: >> >>>I ran into a strange issue trying to do a merge. >> >>Chris, sorry to take so long to get back to you on this. >> >> >> >>>Using the 1.11.21 client delivered with Fedora Core 5 >>>and a server running 1.11.17 (using pserver), cvs would >>>not identify merge conflicts. >>> >>>Grepping through the merged files found the conflicts. >>> >>>The client also allowed committing without resolving the >>>conflicts, but the files with conflicts were not committed. >> >>>No warnings or errors were displayed. Commits of those >>>files with conflicts simply resulted in a no-op, as if there >>>were no differences. CVS diffs also showed no differences >>>when they did exist. >> >>I suspect user error in this case. >> >>This suggests that the conflict markers were checked into the >>repository, and as such did not really create conflicts on your local >>directory. Check out the pre-merged revision of the file into a fresh >>directory. For example, if the update command brought your file to rev >>1.23, and committing it brought it to 1.24, check out rev 1.23. If the >>file contains the merge markers, then it was user error on the part of >>the person who checked in rev 1.23 (or whichever rev. in which the >>markers first appeared). > > > Hmmm. These are exactly the symptoms I'm seeing in 1.12.13...! Not quite. There are subtle, but important, differences between your problem and Chris's. The only way Chris could determine that there was a conflict was by grepping the file for the conflict markers. Checking in the file was a no-op - therefore, CVS saw no differences (as witnessed by cvs diff showing no difference), therefore the conflict markers must have been introduced into the repository before the merge, and were simply inserted as any other normal update. Now, the original cause may have been the same - a 'cvs update' may have cleared the "C" status, thereby misleading the developer into thinking everything was OK and checking it in. But shame on the developer for not double-checking, via a 'cvs diff', before actually committing. - -- Jim Hyslop Dreampossible: Better software. Simply. http://www.dreampossible.ca Consulting * Mentoring * Training in C/C++ * OOD * SW Development & Practices * Version Management -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEgK/8LdDyDwyJw+MRAkk+AJ4kPPpASGQWn/A9CMOCOTeXXiAlEQCg5JgP ix4nZsAZkPkC377iO+JfjmA= =1j07 -----END PGP SIGNATURE----- _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
