>> Here's the patch (Skip's locking the Lib dir ... grrr ;-):
Fredrik> What's causing all these stale locks?
To the best of my knowledge there were two stale locks, both caused by me
(*sigh*) as the result of a single failed cvs diff command. The SF folks
released the lock on Modules but apparently failed badly to respond to two
separate requests (from Barry and me) to release the lock on Lib.
Here's what I think happened (I'm not going to test my theory on the Python
tree lest I bollux up more directories!). I wanted to create a single
context diff containing just the changes I had made to Modules/readline.c
and Lib/rlcompleter.py. I changed directory to my Python top-level
directory and executed
cvs diff -C Modules/readline.c Lib/rlcompleter.py
This failed, as did a couple other permutations I tried shortly after that.
My theory is that "cvs diff" fiddles things a bit then calls the local diff
command. Diff's -C flag is supposed to have a number as an argument (the
number of context lines to display - I should have used "-c", which is the
same as "-C2" I think). Diff exited with a nonzero status. Either rcsdiff
or cvs diff failed to recover properly and we're left with a read lock on
both Modules and Lib.
On a repository here I just tried:
cvs diff -C www/dbserve.py
which gave me the following output:
cvs diff: Diffing GNIS
cvs diff: Diffing conferences
cvs diff: Diffing www
Index: www/Makefile
===================================================================
RCS file: /home/dolphin/projects/www-python/Makefile,v
retrieving revision 1.51
diff -Cwww/dbserve.py -r1.51 Makefile
cvs diff: invalid context length argument
Segmentation fault
And it left the following file in my repository:
-rw-rw-r-- 1 skip users 0 Jul 7 15:54 #cvs.rfl.dolphin.25030
When I try to check in a changed file to that repository I get:
cvs server: [15:57:27] waiting for skip's lock in /home/dolphin/projects/www-python
Delete the lock file and after a short pause I get:
cvs server: [15:58:57] obtained lock in /home/dolphin/projects/www-python
Checking in fsm.py;
/home/dolphin/projects/www-python/fsm.py,v <-- fsm.py
new revision: 1.4; previous revision: 1.3
done
Cute, huh?
So, this confirms what I suspected. There would appear to be a bug in cvs
(I'm using 1.10.7). I will look and see if this is a reported bug and/or
see if there is a newer version of cvs.
Note that this doesn't let SourceForge off the hook. In theory, anyone with
read access to any (or all?!?) CVS repositories at sourceforge.net could
bring them to a screeching halt (at least for a bit) by performing the same
trick on lots of repositories.
my-fortune-cookie-quote-takes-on-new-meaning-ly y'rs,
--
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"To get what you want you must commit yourself for sometime" - fortune cookie
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4