Re: "Stale" CVS locks

[Larry Jones]

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