I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?):
[06:31:40] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:10] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:32:41] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test cvs server: [06:33:11] waiting for anoncvs_python's lock in /cvsroot/python/python/dist/src/Lib/test
I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?):
I haven't seen this myself. Could be you were just unlucky. Could be someone was doing a full checkout over a slow connection.
I think the anon checkouts still use (read) locks because they need to get a consistent version.
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?):
I haven't seen this myself. Could be you were just unlucky. Could be someone was doing a full checkout over a slow connection.
I think the anon checkouts still use (read) locks because they need to get a consistent version.
Looks like someone is using a 9.6kBaud mobile phone connection ;-) The problem still persists and I've been trying for about half an hour now.
I'll try again later today...
Guido van Rossum writes:
I think the anon checkouts still use (read) locks because they need to get a consistent version.
Yes; you need a directory lock to avoid files getting modified or deleted underneath you while checking out/updating.
-Fred
[MAL]
I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?):
IIRC, CVS maintains the illusion of being a multi-user system by using per-*directory* locks. That means it gives you the warm fuzzy feeling that you're being protected against (e.g.) getting an inconsistent snapshot while someone else is committing, but in fact you're not protected at all (inter-directory). It locks per-directory to ensure the integrity of its own data files, but users are subject to the luck of the draw.
Note that Perl is maintained under (the commercial, alas) Perforce, which is one of the few SCMs to take multi-developer multi-directory issues seriously.
So the good news is that when you see a CVS lock gripe, that means CVS is protecting itself from corruption. The bad news is that if we used a system that protected *us* against inconsistencies too, we'd probably see lock gripes even more often.
[MAL]
I'm getting loads of lock messages during CVS checkins recently. Is this due to overload ? (I wonder why anoncvs access causes locking at all -- there is no write access so why should there be file locking ?):
IIRC, CVS maintains the illusion of being a multi-user system by using per-*directory* locks. That means it gives you the warm fuzzy feeling that you're being protected against (e.g.) getting an inconsistent snapshot while someone else is committing, but in fact you're not protected at all (inter-directory). It locks per-directory to ensure the integrity of its own data files, but users are subject to the luck of the draw.
Yes, that's how it works...
Note that Perl is maintained under (the commercial, alas) Perforce, which is one of the few SCMs to take multi-developer multi-directory issues seriously.
We tried Perforce at CNRI. It's really neat, but somehow it was lacking some stuff we were used to and we never converted.
Note that Perforce is free for open source projects -- at least at the time it was. (CNRI paid a license fee, but that was just an expression of CNRI's reluctance against free software. :-)
There's also bitkeeper. It stayed in beta so long that we gave up (and they have a weird license) -- but it's out of beta since May 4: see http://www.bitkeeper.com/. But there's no immediate download! You must sign up and they send you instructions in the mail...
So the good news is that when you see a CVS lock gripe, that means CVS is protecting itself from corruption. The bad news is that if we used a system that protected *us* against inconsistencies too, we'd probably see lock gripes even more often.
Well, the implementation could save the previous consistent version and give you that while an update was under way... There are other ways to protect against inconsistencies. But I'm not sure that you always *want* this -- as a system grows, it's better to be able to deal with inconsistencies than to try to avoid them (and have the world blow up in your face when the avoidance fails).
Anyway, I submitted a service request to have the lock in the Lib/test lock removed. (Apparently some process didn't clear up its lock. That's rare, but sometimes it happens.) It's been fixed now, so checkins in the Lib/test directory should move forward again.
--Guido van Rossum (home page: http://www.python.org/~guido/)
I recently made the conversion from CVS to PRCS. I like PRCS much better. It is easier to use, implemented indepentant of rcs, faster, more flexible and has versioned project meta-data. Branching and merging is much simpiler than CVS. Operations on project versions are atomic. Renaming and moving files is easy. It is well documented.
Unfortunately version 1 does not support distributed repositories. Josh has informed my that version to is coming (hopefully this year) and will support distributed repositories.
For Python I don't think that a multi-user version control system is strictly necessary anyhow. The PRCS repository could be made available via rsync and a process could be setup for checking patches into the central repository. It should actually be more efficient than the current CVS setup.
I just looked at the webpage and the beta for 2.0 is out:
http://www.xcf.berkeley.edu/~jmacd/prcs.html
If PythonLabs is interested in using PRCS I will even volunteer to make sure those Windows weenies have a good port. :)
Neil
I was just looking at Josh's work last week, and thought it looks quite interesting. Despite my interest, I don't expect we would use it for Python unless SourceForge adopted it. We moved the Python CVS tree to SourceForge to avoid maintaing a large installation of software development/management tools.
Jeremy
On Thu, Jun 29, 2000 at 02:05:11PM -0500, Guido van Rossum wrote:
...
Note that Perl is maintained under (the commercial, alas) Perforce, which is one of the few SCMs to take multi-developer multi-directory issues seriously.
We tried Perforce at CNRI. It's really neat, but somehow it was lacking some stuff we were used to and we never converted.
Note that Perforce is free for open source projects -- at least at the time it was. (CNRI paid a license fee, but that was just an expression of CNRI's reluctance against free software. :-)
There's also bitkeeper. It stayed in beta so long that we gave up (and they have a weird license) -- but it's out of beta since May 4: see http://www.bitkeeper.com/. But there's no immediate download! You must sign up and they send you instructions in the mail...
And coming down the pipe (end of the year) is Subversion:
Cheers, -g
participants (7)
-
Fred L. Drake, Jr. -
Greg Stein -
Guido van Rossum -
Jeremy Hylton -
M.-A. Lemburg -
Neil Schemenauer -
Tim Peters