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.
Chris, > Actually, I do not think it is the sandbox. Here is why... > > Once the first commit fails, NO existing sandbox can commit > that file. I suppose it is possible that 10+ developer > sandboxes are simultaneously becoming corrupted around > particular file, even if they do not touch that file. > However, that seems unlikely to me. However it is also easy to see that it is not the repository since checking out a new sandbox and performing a commit from there 'fixes' the problem. This in turn will require an 'update' on the other sandboxes which may very well 'fix' the other 10. Given that your sandboxes are used by Eclipse and TortoiseCVS it could be that Eclipse is modifying something in the CVS Admin files in the 'broken' sandboxes that the CVSNT client is not handling as well as it could/should. With this scenario 10 broken developer sandboxes is not too hard to imagine. Regardless - if a 'new' sandbox 'fixes' the problem the server repository is not 'corrupt' (if it was no sandbox new or old would work). If you can regularly reproduce this problem, to investigate what we are going to need are the CVS\* files from the directory where the commit is failing and you will need to enable 'clients are allowed to trace server' on the server, then on the client set CVS_CLIENT_LOG=log20050622 and then run 'cvs -ttt commit -m ""' on the client and send to support at march-hare.com the log20050622.in, log20050622.out, zip of CVS\* and the trace. Then do the same on a 'fresh' sandbox and send the 'working' results. Once you've sent the logs through - send a fresh post in this thread to the newsgroup saying that you've sent them or else the logs will be discarded at our end. Regards, Arthur Barrett