[cvsnt] Crash during checkout

Fri Feb 25 23:10:09 GMT 2005

Hello,

I recently migrated from CVS 1.11 to CVSNT 2.0.58 but I'm experiencing
a few problems. Here's is a few of the major ones. Thank you very much
for your support.

1. I get a crash during checkout on a specific file. It hangs on the
client side and the server prompts to create a crash dump. However, a
-r checkout does not cause it to crash. Is this problem known for
files originally checked in with CVS 1.11? Please let me know if more
information is needed.

2. Editing procedure. I have been getting complaints from developers
used to working with CVS 1.11. One scenario is that since the files
are checked out as read/write, they can go in and modify the files
without using the edit command. After modification, the developer
remembered it and performed the edit command. However when he tried to
commit the file afterwords, the server did not produce a response (and
he did not write a revision message). Thinking that the file had been
committed anyway, he updated it and loss his changes. If this is a
user error with CVSNT? CVS 1.11 supports this procedure.

3. Developers using VB had problems merging files. Developer1 edits
FileA (text based). Developer2 edits FileA. Developer1 updates,
changes and commits FileA with a new revision. Developer2 updates
FileA and receives the M FileA message. However, the changes expected
from Developer1 were not included in Developer2's new copy, although
he received a new revision. There are two scenarios that I could think
of:

a. Developer1 could have mistakenly checked in the wrong working copy of FileA.
b. For some reason, maybe dealing with VB dependencies with binary
files, the changes were lost with the new revision.

This problem was only seen with the group using VB. User error has not
been ruled out (until I am able to sit down with them, but they claim
to check in the right ones). I emailed about this before but could not
provide any more details than this.  Does anyone have any insight on
this?

4. Due to problem #3, the temporary solution was to use exclusive
locks to prevent the loss of changes. However, this caused another
situation: Developer1 has FileA locked. Developer2 tries to edit FileA
but the server refuses. Every subsequent command by Developer2 in the
same command prompt (cvs update, commit etc) will result in the server
refusing to edit FileA. Developer1 then unlocks the file and
Developer2 restarted his machine and everything worked fine.

5. Migration question: I was responsible for the migration from the
nix box to a new nt server. I basically performed a copy of the nix
source to the new repository set up on the nt server. This did not
include CVSROOT. Did I do this right? Everything seemed to work OK as
the history, logs and revisions looks intact. However, after
experiencing problems, including those above, I have begun to question
my migration work.

Thank you. I appreciate it very much. 
David