[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
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden CollabNet ( http://collab.net )
--
Since English is a mess, it maps well onto the problem space,
which is also a mess, which we call reality.
- Larry Wall