[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
inadvertent unlock
From: |
Joe Orchard |
Subject: |
inadvertent unlock |
Date: |
Tue, 12 Mar 2002 16:28:19 -0800 |
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"
- inadvertent unlock,
Joe Orchard <=