[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Non-DoD Source] Re: CVS lock issue
From: |
Glasgow, Steven R CIV USARMY TRAC (US) |
Subject: |
RE: [Non-DoD Source] Re: CVS lock issue |
Date: |
Fri, 16 Feb 2018 13:08:30 +0000 |
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
- CVS lock issue, Glasgow, Steven R CIV USARMY TRAC (US), 2018/02/15
- Re: CVS lock issue, Spiro Trikaliotis, 2018/02/15
- RE: [Non-DoD Source] Re: CVS lock issue, Glasgow, Steven R CIV USARMY TRAC (US), 2018/02/15
- RE: [Non-DoD Source] Re: CVS lock issue, Glasgow, Steven R CIV USARMY TRAC (US), 2018/02/15
- Re: [Non-DoD Source] Re: CVS lock issue, Spiro Trikaliotis, 2018/02/15
- Re: [Non-DoD Source] Re: CVS lock issue, Thorsten Glaser, 2018/02/15
- Re: [Non-DoD Source] Re: CVS lock issue, Spiro Trikaliotis, 2018/02/16
- RE: [Non-DoD Source] Re: CVS lock issue,
Glasgow, Steven R CIV USARMY TRAC (US) <=
- Re: [Non-DoD Source] Re: CVS lock issue, Mark D. Baushke, 2018/02/16
Re: CVS lock issue, Thorsten Glaser, 2018/02/15