Re: CHECKIN/CHECKOUT - Versioning Policies?
Yaron Goland (yarong@microsoft.com)
Tue, 19 Jan 1999 21:15:23 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D52@RED-MSG-59>
From: Yaron Goland <yarong@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
Date: Tue, 19 Jan 1999 21:15:23 -0800
Subject: RE: CHECKIN/CHECKOUT - Versioning Policies?
Welcome to the fourth and final entry in my series of comments on Geoffrey's
proposal.
>
> Specifying CHECKOUT/CHECKOUT-NEW Policy
>
> For versioning individual documents, it is sufficient to just let the
> user select CHECKOUT or CHECKOUT-NEW, as they see fit. For
> versioning sets of related resources that are being modified in
> parallel by multiple users over the course of multiple sessions, it is
> essential that the server provide a mechanism for the client to store
> its versioning policy in a form that can be queried (and updated) by
> multiple clients over multiple sessions. This is especially true when
> the CHECKOUT choice for a particular resource is dependent on the
> current state of the revision graph for that resource. I propose that
> the "workspace" resource that stores the version-selection-rules is
> the appropriate place to store this information, since the
> modification
> and creation of new revisions must be synchronized with the
> version-selection-rules, or else newly created revisions might
> disappear from view as soon as they are checked in.
>
Client versioning policy? I thought we killed this back in '97!
In December of 1996 Andre van der Hoek put forward a post to the list that
summarized a proposal he had made previously to the authors
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1996OctDec/0199.html). In
essence it proposed that clients be allowed to tell servers what their
versioning policy is.
The issue was investigated, at length, by the working group and the proposal
was rejected in its entirety. The reason for the rejection was as follows:
1) Many DM vendors indicated that their users demanded the ability to
specify a single versioning policy for their server and would demand that
all clients that interoperate with their server must use that versioning
policy. The key issue wasn't the particular policy the server used so much
as the ability of the server to absolutely rely upon a particular policy
always being used across all its resources. Without this guarantee it became
impossible to apply meaningful security policies and to interoperably share
versioning data across resources since the knowledge needed to understand
the information changed based on which client used which policy against
which resource. Matters became especially bad if clients were allowed to
change the policy on a resource once the policy had been established.
2) Client vendors indicated that their clients would be written to use a
particular versioning policy and would refuse to interoperate with any
server which did not implement that policy. The basis of their reasoning was
that the UI the client implemented had to be tuned to a particular policy.
If the policy could change based on the resource being talked to then the UI
would have to change with it. Furthermore, it is hard enough to write a
client which supports a single versioning policy. It is next to impossible
to write, debug, document, and then educate one's users about a client whose
policy could change on a resource by resource basis.
At the same time the WG got an "in your face" demonstration of just how bad
variable policies could be in terms of code and protocol complexity. After
Andre's post in Dec '96 there was a WebDAV WG meeting in Irvine in Jan '97.
At the time the various DM vendors refused to compromise in how versioning
worked. Each insisted that versioning must work exactly the way their system
implemented it. For example, we couldn't get consensus on an issue as simple
as "if you do a check out is there a working draft? If so, is it created on
the server or the client?" So Jim and I presented a protocol that did
everything everyone wanted. I only think it required three round trips and 8
different axis's of negotiation. You can see some of the discussion on both
client versioning and policies and on the versioning design noted down as
part of day two in
http://www.ics.uci.edu/%7Eejw/authoring/irvine/minutes.txt. Unfortunately
the meeting notes don't do a great job of recording the discussions that
various comments sparked. Those of you who really enjoy pain can check out
section 9 of http://www.ics.uci.edu/~ejw/authoring/webdav-draft-06.html for
the details. Try not to laugh/cry too hard.
But the point was made, negotiation and variable policies didn't work. While
I realize that the policies discussed here are not the same as those
discussed in the document I believe the line of reasoning that made us
reject policies in '97 will lead us to the same conclusion in '99.
Either way, in '97, the WG consensus was that there would be no negotiation
on versioning policy. Neither clients nor servers would be allowed to
dictate policy. Rather the WG instructed the authors to come up with a
single policy and make that the standard.
> Bottom line: A CHECKOUT, CHECKOUT-NEW, and CHECKIN command, with no
> special CHECKOUT/IN headers (which should make Larry happy :-).
>
> Note for Dave: The CHECKIN-NEW would be used to produce the "anonymous
> new change-set" you wanted.
>
> Note for Brad: A workspace property would be used to achieve the
> -force_branch_on_new_version functionality that you wanted.
>
> Note for All: This doesn't discuss UNCHECKOUT.
>
> Cheers,
> Geoff