[cvsnt] Re: recovery from misfired commit

Anna Seg segfault at noao.edu
Tue Feb 18 17:27:29 GMT 2003


>>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-



More information about the cvsnt mailing list