RE: [Non-DoD Source] Re: CVS lock issue

[Glasgow, Steven R CIV USARMY TRAC (US)]

Hello Spiro,

Thank you; you have been most helpful, but here is what I think is going on.  I 
have a hunch the source of the problem is ... tagging doesn't follow the same 
locking guidelines as committing or checking out.  We see "waiting for xxxx's 
lock in yyyy" all the time.  CVS does control locking on a directory by 
directory basis.

According to the documentation I've read before, revisited yesterday, and was 
pointed to by Thorston on this CVS list yesterday (after being chastised for 
obscuring my filenames, as if my file names add anything to the discussion):

To obtain a write lock (I assumed tagging would be doing this as it does when 
committing), you must first create a #cvs.lock (master lock) directory.  If you 
can't do this for some reason (i.e., someone else already created it) wait a 
while and try again.  This is the source of the waits we see.  After you are 
able to create the master lock directory, check to see if there are any 
#cvs.rfl.<machineName> files.  These would be read locks created by the user of 
machineName (i.e., checking out) in that directory.   If there is a read lock, 
remove the master lock and wait a while before trying again.  If there are no 
read locks the directory is yours and you can create a #cvs.wfl.<machineName> 
file.  This is a write lock for the directory.  Write to the file of your 
choice, remove the write lock, and then remove the master lock.  By holding 
onto the master lock while writing, removing it last, you prevent anyone else 
from writing to that directory in the repository while you are (on a directory 
by directory basis).

Now in reference to our error message:

cvs [tag aborted]: could not open lock file `<path>/,<filen+2>.cc,`: File exists

Thorsten said, "These are not lock file names. Lock files are named like 
#cvs.*, and there are several types of locks."  We already knew that, but the 
tagging operation clearly tried to create a file called ,<filen+2>.cc, and it 
called it a lock file (I didn't make that up).  So, tagging seems to be doing 
things a little differently and not taking advantage of the master lock/write 
lock process.

I think this is what happened:

1) Developer #1 started tagging a module.
2) Developer #2 started tagging that same module.
3) During the course of this:
        a) Developer #1 created ,<filen+2>.cc, in the <path> directory
        b) Developer #2 then tried to create ,<filen+2>.cc, in that same 
directory but couldn't because it already existed, stopping their tagging 
process.
        c) Developer #1 tagged the file and deleted <path>/,<filen+2>.cc, which 
is why it is now gone.

If the tagging process was using the locking mechanisms, developer #1 would 
have obtained the master lock for the <path> directory, causing developer #2's 
process to wait.

Could this be what is happening?  Because of the speed at which tagging occurs, 
I see this as a VERY rare occurrence, but still a problem.

I know that CVS does not do atomic commits, but after having used CVS for over 
15 years on our project, we have never had any issues.  This is the first time 
I've ever seen this problem.  CVS has supported us well.  There have been many 
thoughts over the years about moving to Subversion, but this may have been the 
last straw to force us to move that direction.  When the tagging of a module 
does not complete, it is very difficult to grab that version of the code in the 
future (the other option at that point would be to check out by time rather 
than by tag).

Thanks again,
Steve