Re: Merge issue using client 1.11.21 and server 1.11.17

[Jim Hyslop]

-----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-----