[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs tag and #cvs.lock

From: Dewey M. Sasser
Subject: Re: cvs tag and #cvs.lock
Date: 05 May 2003 08:04:41 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

"Paul Edwards" <kerravon@nosppaam.w3.to> writes:

> "Larry Jones" <lawrence.jones@eds.com> wrote in message 
> news:mailman.5533.1051984031.21513.bug-cvs@gnu.org...
> > 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
If Bill Gates had a nickel for every time Windows crashed...
Oh wait!  He does!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]