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

Chris Kaler (
Tue, 1 Dec 1998 10:37:33 -0800

Message-ID: <4FD6422BE942D111908D00805F3158DF0A75794D@RED-MSG-52>
From: Chris Kaler <>
To: "'David G. Durand'" <>,
Date: Tue, 1 Dec 1998 10:37:33 -0800 
Subject: RE: checkout/checkin/uncheckout vs. lock/unlock

And my grandfather's model T had a crank to start :-) just kidding....

You are right that CVS doesn't require it, but many systems do tie the two
together, so I believe we must have a way to do it.  I also think that this
is a primary case.  I'll take your point about CVS and say there are two
primary cases: (1) no lock, (2) lock.  For primary cases I would prefer to
limit the round-trips required to the server.  As well, many systems provide
a way to discover the current checkouts even if CVS doesn't.  So here is the
point.  You may want to take a lock, you may want to discover the checkouts,
you may want to search on the active checkouts.  We have a mechanism in DAV
that supports these operations, LOCK.  I understand that if you don't want
to lock the resource it may seem odd to use LOCK to checkout, but this does
seem cleaner than having to make two requests and define new discovery and
searching semantics/operations.


		-----Original Message-----
		From:	David G. Durand []
		Sent:	Tuesday, December 01, 1998 5:02 AM
		Subject:	Re: checkout/checkin/uncheckout vs.

		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
		appropriate to call it a lock, or to overload the locking

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