[Top][All Lists]

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

Re: "Stale" CVS locks

From: Derek R. Price
Subject: Re: "Stale" CVS locks
Date: Tue, 12 Jun 2001 15:33:34 -0400

"Reinstein, Shlomo" wrote:

> Hi,
> It happens many times that CVS users execute some CVS command (e.g., cvs
> log), and then, before it finished executing, they abort the command using
> Ctrl+Break or a similar manner. The outcome of this is that the read locks
> generated by CVS remain in place, and prevent other users later from
> checking-out modules (or performing other CVS operations on these modules
> that contain the read locks).
> I'd like to know, is there a common way of handling these problems? If not,
> can you recommend us how to deal with this? If don't know if it matters for
> this problem, but we're using CVS (the same repository) from both Windows
> and Linux, and we're not using the client/server model of CVS (and we can't
> start using this model now). The Ctrl+Break case may perhaps be solved by
> capturing those keystrokes, but there may be other reasons for stale CVS
> locks such as when a machine crashes, so I think this problem should be
> solved more generally.

What version of CVS are you using?  In general, CVS will clean up after
itself, ctrl-break or no.  A hard kill (kill -9) or a server core dump or
system crash could still leave lock files around, but these are currently
deemed to happen infrequently enough that extra handling (beyond a sysadmin
going in and deleting the files) is unecessary.


Derek Price                      CVS Solutions Architect ( )
mailto:address@hidden         CollabNet ( )
Since English is a mess, it maps well onto the problem space,
which is also a mess, which we call reality.

        - Larry Wall

reply via email to

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