inadvertent unlock

[Joe Orchard]

I hesitate to even raise this question at all for fear that the CVS 
gods will flame me into oblivion. But, I have been RTFM for about 2 
months now as well as searching the web repeatedly. However I have 
been unable to answer/fix a problem that the developers who are 
beginning to use CVS here at my work have. 
 It has to do with the "Lock" command(admin -l). The scenario I am 
being asked to "fix" is one where say USER1 locks the file OPEN.cpp 
because they are doing a massive change to the file and does not want 
to have to do any merging when they commit the file. Next USER2 come 
along and at some level about the dir where OPEN.cpp sits does a 
recursive admin -l. Of course the command will error out at OPEN.cpp 
because USER1 has the file "locked". USER2 talks to USER1 and finds 
that he needs to wait until after USER1 has finish with OPEN.cpp to 
begin his work. User1 assures USER2 that he will let USER2 know as 
soon as he is done with OPEN.cpp. So, USER2 goes back do his desk  
and to be a good concurrent revision developer does a recursive admin 
-u to unlock all of the files that he,USER2, just locked. HOWEVER, 
with the way CVS works, or is setup, or not setup,  I do not know 
which, this also unlock the file OPEN.cpp that USER1 locked AND any 
others that USER1 or anyone else has locked. Now USER3 comes along 
and locks the entire Dir that OPEN.cpp is in. The command completes 
successfully because there is no lock on any of the files including 
OPEN.cpp. Now when USER1 goes to comment his changes he will get the 
error ,much to his surprise, that USER3 has the file locked. Note: 
all three users are part of the group that and in the CVSADMIN group 
and can user the ADMIN command as they see fit. Several developer 
have brought this to my attention and I the feeling the they would be 
willing to work around this but what they are most concerned with is 
if One Developer locks a number of files to make a LARGE change and 
informs everyone that when they see that the locks are gone they can 
work on the files. But if anyone can unlock the files by doing one 
recursive unlock and if this is done accidentally at a top level of a 
module, this can cause a lot of headache and confusion. I do 
understand the need for communication. But, accidents are going to 
happen. People will not realize exactly what they are about to do 
until it is to late. My question is: Is there a way to avoid that 
situation? Oh, I know that ADMIN -l is a hack and that in a "TRUE" 
Concurrent revision control environment that it will never be used. 
But I am not the Development manager and can not change the whole 
company to unreserved checkout. And yes i know that only one or two 
developers should have access to the ADMIN command, but again I do 
not make the rules here. So, please forgive me but I am in between a 
rock and a hard place. Simply put, can you keep USER2 from unlocking 
the files USER1 has locked? Is it at all possible to do so. If there 
is information about how to set this up is in the manuals, I have 
missed repeatedly. can you please point me to it. Or is this not 
possible. Can anyone unlock anyone else's locked files? If so, is 
this by design? Or is this just how cvs works? Can you explain the 
reason for anyone being able to unlock any file at any time they 
want? And again if this information is anywhere in the manuals or on 
the web i have missed it. Can you please point me at it so i can deal 
with this issue.

Thanks in advance for any help you can give me.

-- 
Joe Orchard
Network Administrator
Conducive Technology Corp.
Portland, OR

  ___________________          _-_
  \__(==========/_=_/ ____.---'---`---.____
              \_ \    \----._________.----/
                \ \   /  /    `-_-'
           __,---`.`-'..'-_
          /____          ||
                `--.____,-'

"To boldly go where no man has gone before"