- From: Christopher Seiwald <seiwald@perforce.com>
- Date: Tue, 3 Sep 1996 16:38:20 -0700
- To: w3c-dist-auth@w3.org, www-vers-wg@ics.uci.edu
| From: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> | | > Now Roy Fielding says that Content-Version is opaque and could | > be used exactly for this purpose, 'cause no one would be the wiser | > if the Content-Version were different for each checkout of the | > same document. This is true, but now the names of these fields | > are losing their meaning, no? If it's checkout context, call it | > "Checkout-Context" (or "Checkout-Cookie"). | | Checkout does not have meaning on all systems, whereas version has a generic | meaning (at times, too generic). It is intended to be as flexible as possible. | The "Content-" prefix is a requirement of MIME for what HTTP calls | entity-header field names. Not to beat a dead horse (but this one's still kicking): I'm pushing for us to recognise "checkout" as a meaningful act for the version abstraction we are trying to support, whether or not the underlying system can make real use of it. It means "GET the SOURCE for EDIT". "GET" because the document has to be fetched (or via existing methods determined that the user has the requested copy), "the SOURCE" because the user needs the document as it is prior to any server-side interpretation, and "for EDIT" so that the VC backend is aware of the user's activity. All VC systems can cook up a checkout cookie; some VC system will have difficulty without one. The simpler systems - RCS, SCCS, and CVS may well be wrapped with some layer that provides the context. Here's how I see them being used, again with Perforce thrown into the mix because it has fairly modern VC semantics: CHECKOUT LOCK CHECKIN ---------------------------------------------------------------------------- RCS Probably just Verifies that Verifies SCCS emits URL+version, the cookie that cookie so that the represents represents subsequent the head rev. LOCKed rev. LOCK or SUBMIT May be a no-op can make sure user if the SCCS/RCS has the head rev. wrapper does May imply LOCK, LOCK on CHECKOUT. since RCS/SCCS don't normally support unlocked checkout. CVS Emits the line Throws up its Verifies from the CVS/Entries hands because that cookie file that reflects CVS doesn't represents the file+rev being support locking. head rev. edited. ClearCase Emits view-extended Verifies that Verifies pathname and rev of cookie represents that cookie file being checked out. checked-out file represents Because of CC's auto- and does a CC LOCKed rev. branching, the rev may reserved checkout. be different that what was requested. Perforce Emits client pathname Verifies that Verfies and rev of file cookie represents that cookie being checked out. checked out file. represents head rev. There is use for the checkout cookie for all these systems, even if the cookied degrades into being little more than "Content-Version". Since All VC systems can make use of the cookies, and some need them for sane operation (checkin without checkout under clearcase is a no-go), it makes sense to use a single tag across all underlying VC systems. IMHO, of course. Christopher
Received on Thursday, 5 September 1996 12:34:12 UTC