Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Thank you for the replies. Regarding #1, it seems like fileattr.xml is
the cause of the client hang and server crash. Here's what it looks
like:
<fileattr>
<directory>
<default>
<watched />
</default>
</directory>
<file name="J&B-ProfessionalServices-20020922.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20021103.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20021202.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-2003-TBD.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20030126.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20030223.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20030629.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20040225.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-Backup.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20040427.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20041118.xls">
<watched />
</file>
<file name="J&B-ProfessionalServices-20050119.xls">
<watched />
</file>
</fileattr>
After I remove this file, the checkout does not hang. However, I
noticed that the server still crashed (prompts to produce the crash
dump) with no indication from the client side. I then removed the
Attic folder in the problematic module and now all is well. Any
thoughts?
Regarding #2, I tried the "cvs watch on" which did not create the
files as read only. When I tried to run the command again, it hangs.
Am I missing something about how #2 always worked this way? Since the
files are editable upon checkout, a developer can modify it without
the cvs edit command and perform a commit. However, what if the
developer runs the cvs edit command after modification? If the file is
not resaved, the commit does not go through. So the file state is
based upon when the user runs the cvs edit command. Thus, I can go to
the files and modify them before running an edit. Then, I'll do a cvs
edit on those files. If I modify the files after the edit, and then
perform a cvs unedit to revert the changes, I'll end up with the file
at the time of the cvs edit command. Is this how CVS1.11 worked?
On Fri, 25 Feb 2005 15:10:09 -0800, David Vo <vo.david at gmail.com> wrote:
> 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
>