lock/checkout/reserve/edit

Christopher Seiwald (seiwald@perforce.com)
Tue, 3 Sep 1996 11:12:29 -0700 

With deference to David's work, I'd like to try to straighten out our
nomenclature here.  I don't want to say that just because existing
version control products use this terminology then the web based versioning
must as well.  But at least _I_ would like to be understood.

Many products on the market are derived from RCS or SCCS (or are in fact
RCS or SCCS), and share their terminology.  I'm adding our own product
(Perforce) because its terminology is a superset of the others.

Just to get going, here are the states a VC client can be in w.r.t. a 
file/document, and who supports those states:

	A)	Doesn't have the document in its possesion.

		o   ClearCase doesn't state A, because with its virtual
		    filesystem clients are already soaking the filespace of
		    the repository.

	B)	Has the document, but not the permission to change it.

		o   CVS has no state B, because if you have a file you can 
		    change it.

	C)	Has the document, with the permission to change it.

		o   RCS and SCCS have no state C -- if you have permission
		    to change a file, you also have the exclusive lock on it
		    (state D).

	D)	Has the document, the permission to change it, and the
		lock on the copy in the repository.  This client has the
		right of way to create the next revision in the repository.

		o   CVS has no state D, because it doesn't support exclusive
		    locks.

The transitions:

	A->B	ClearCase:	none (no state A)
		CVS:		none (no state B)
		RCS:		"unreserved checkout" 
		SCCS:		"get"
		Perforce:	"get"

	B->C	ClearCase:	"unreserved checkout".
		CVS:		none (no state B)
		RCS:		none (no state C)
		SCCS:		none (no state C)
		Perforce:	"edit"

	A->C	ClearCase:	none (no state A)
		CVS:		"checkout"
		RCS:		none (no state C)
		SCCS:		none (no state C)
		Perforce:	"get" + "edit"

	C->D	ClearCase:	"reserved checkout"
		CVS:		none (no state D)
		RCS:		none (no state C)
		SCCS:		none (no state C)
		Perforce:	"lock"

	B->D	ClearCase:	"reserved checkout"
		CVS:		none (no state D)
	    	RCS:		"reserved checkout" 
		SCCS:		"edit"
		Perforce:	"edit" + "lock"

As you can see, it's a mess: ClearCase and RCS use the same term for
two entirely different transitions.  Basically, the word "checkout" can
mean any progression from one state to the next, depending on which 
product you're using.

Here's what I propose, based on a seat-of-the-pants understanding of
which way the terminology is going:

	A->B	Proposed:	"GET" (HTTP's, mind you)
	B->C	Proposed:	"CHECKOUT"
	A->C	Proposed:	"CHECKOUT"
	C->D	Proposed:	"LOCK"
	B->D	Proposed:	"CHECKOUT" + "LOCK"

N.B. that "CHECKOUT" == "GET for EDIT", previously used.

I'm not suggesting that these are new HTTP verbs, but rather that we
use these terms when hashing out our other ideas.

Comments?

Christopher