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.
>>Problem #1: It left the lock files in the repository which denied >>access to the directory via the client. > > > When the client died the server should have removed the locks > automatically. That kind of thing happens occasionally here and > there's never been a problem with it. > > What's your CVSROOT? You're not using local mode I assume??? Correct. My CVSROOT on the wincvs GUI is user at host:/path (sspi authentication). The server and the client are both on a local windows domain. >>My solution: Deleted the lock files on the cvsnt server machine. >> >>Problem #2: After the lock files were deleted, I tried to commit the >>file again, and it *still* hung (I think the repository was confused). > > > Define 'hung'. The worst that you should ever need to do is delete hung = the client (wincvs) didn't return from the call to commit. It seemed like it was waiting for something, that something never happened, and then the dos shell it spawned just stayed open and the fishes in the corner kept on swimming. I waited 120 seconds before I killed the client process manualy, but I never killed any procs on the server. > the lock files (and if you're using the lockserver, even that becomes > unnecessary). very occasionally a server process will get stuck and > need to be killed (by bringing up a system-priviliged task manager or > using a 'kill' tool) but that's thankfully rare these days. > > >>My solution: Deleted the file.ext,v in the repository, then used the >>wincvs client to re-add, then commit. This seemed to work. > > > That's a bit drastic, and is never necessary... you lose all your > history that way, not to mention confusing the clients. I guess this goes back to the hanging problem. I would have used the client tool to manage the file, but every time I tried the client tool would never return from the call to the server. The 'file,v' file on the server contained no data from the file at all, just a header (this problem happened on a first time commit). This problem arose from trying to commit a file that wasn't accesible by the client. The header was created on the server, but the file was never checked in. What should the behavior be if a module is checked out from the server that contains a file that was added, but never commited? Can another client check out that module, then commit the file for the first time, or does the same client that added the file have to commit the first time also? Thanks for helping me; I know the error is most likely in the user, and not the application... -Anna-