Re: cvs tag and #cvs.lock
[email protected] (Dewey M. Sasser)
| Newsgroups | gmane.comp.version-control.cvs.bugs |
|---|---|
| Message-ID | <[email protected]> |
"Paul Edwards" <[email protected]> writes: > "Larry Jones" <[email protected]> wrote in message news:[email protected]... > > Paul Edwards writes: > > > > > > On CVS 1.11.5 on Solaris someone did a "cvs tag" (not rtag) > > > and then ctrl-c'd it, and it left a #cvs.lock in the repository. > > > > > > This is a local repository. > > > > > > Does CVS not handle this cleanly? > > > > It's supposed to -- it works for me. All I can think of is that someone > > did something more drastic than ctrl-c (like ctrl-\) or managed to do > > ctrl-c a second time before CVS had finished cleaning up. > > Multiple ctrl-c's are something that is often seen done by > Unix types (although I don't know about this specific instance). > Should a sig-ignore be done whenever the ctrl-c handler is > invoked to handle "common user practice"? Or a handler > that says "stop interrupting me, I'm working as fast as I can > on the original instruction"? For what it's worth, I suggest not silently ignoring ctrl-c characters. Folks wonder what's up and try it a few more times. With slow networks and large repositories it's very easy to hit ctrl-c a second time before cleanup is finished. Incidentally, I also saw the orphaned lock files using WinCVS and command line clients to NTCVS pserver before they put in a separate locking server. Yes, even using pserver if you killed the client the server process would *not* finish cleaning up lock files. -- Dewey M. Sasser [email protected] --- If Bill Gates had a nickel for every time Windows crashed... Oh wait! He does!