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... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

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/)

[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 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