[Python-Dev] CVS locks on SF

[Guido van Rossum]

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