RE: Merge issue using client 1.11.21 and server 1.11.17

[Jensen, Chris]

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:jhyslop@dreampossible.ca] 
Sent: Friday, June 02, 2006 2:39 PM
To: Steve McIntyre
Cc: Jensen, Chris; bug-cvs@nongnu.org
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-----