[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Stale" CVS locks
From: |
Larry Jones |
Subject: |
Re: "Stale" CVS locks |
Date: |
Tue, 12 Jun 2001 14:02:48 -0400 (EDT) |
Reinstein, Shlomo writes:
>
> 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).
That shouldn't happen -- CVS (at least the Unix version) traps the break
signal and cleans up the locks before exiting. If this really happens,
it's a bug in your CVS. Please report it as such, but be sure to
identify the specific version and release of CVS that it applies to.
> 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.
The problem occurs so rarely in practice (at least on Unix-like systems)
that removing the stale locks manually has been a perfectly reasonable
way to address the problem. It sounds like you're using a network-
mounted repository (Samba?), which is practically begging for trouble,
so you shouldn't be surprised that you're finding it. You really should
switch to client/server CVS -- why do you say you can't?
-Larry Jones
Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin