Re: checkout/checkin/uncheckout vs. lock/unlock

David G. Durand (
Tue, 1 Dec 1998 09:01:55 -0400

Message-Id: <v04011700b289983004fa@[]>
In-Reply-To: <>
Date: Tue, 1 Dec 1998 09:01:55 -0400
From: "David G. Durand" <>
Subject: Re: checkout/checkin/uncheckout vs. lock/unlock

At 6:20 AM -0400 12/1/98, Ben Laurie wrote:
>Chris Kaler wrote:
>> There are several types of locks.  Shared, Advisory, and Exclusive.  I
>> cannot see why you would (in most cases) want to check out a resource
>> without taking one of these locks.  In a collaboration world, you want to
>> know who else is working on the document.  Locks provide an existing
>> mechanism to discover and manage this information.
>CVS is widely used for collaboration, and in the standard mode of
>operation no locks are taken out and there is no way to know who else
>has anything checked out. In fact, to "release" a version under CVS you
>can just do rm -r...

I was going to say "my point exactly" but in fact the CVS model is _more_
radical -- there's really no need for even a checkout operation in that
model. Checkout is sufficient to provide notification, etc. It's doubtful
that all of the notification and status mechanisms for locks will be
exactly the same as those for collaboration. Even if the mechanisms are the
same, if the operations are combined, you can't implement separate policies
for the two situations. And that's clearly more suspect.

To me the similarities in notification and discovery can't hide the basic
disconnect with repect to core functionality: a checkout simply need not
lock anything (depending on server policy). Given that, it's not
appropriate to call it a lock, or to overload the locking methods.

  -- David
David Durand      \
Boston University Computer Science        \  Sr. Analyst   \  Dynamic Diagrams
MAPA: mapping for the WWW                    \__________________________