RE: Autoversion confusion

> Tim, what you've described can make sense, but it leaves
> an unspecified hole in the middle.
>
> If a client does a CHECKOUT then a PUT then a GET, what body
> do they see?

If we are talking about a checked-in version-controlled resource, say
/foo.html, then

CHECKOUT /foo --> makes /foo.html a checked-out version-controlled
resource,
PUT /foo --> updates the content of the checked-out VCR,
GET /foo --> gets the content of the checked-out VCR (i.e., whatever you
just PUT).

If we are talking about a version, say /his/12/ver/3 (and the server
supports working resources):

CHECKOUT /his/12/ver/3 --> creates a working resource whose URL is returned
in the Location: header (say, /wr/45) and leaves the version unchanged,
PUT /wr/45 --> updates the content of the working resource,
GET /wr/45 --> gets the content of the working resource (i.e., whatever you
just PUT),
GET /his/12/ver/3 --> gets the content of the version (it will be unchanged
by any of this).

[Obviously I've left of the http://hostname... from the URLs]

> You say "when a version-controlled resource is checked-out, its
> C&DP are not necessarily the same as any version."  That's not
> much of a requirement!

Well once the VCR is checked-out it is mutable, so subsequent PUTs and
PROPPATCHes will be altering its state.  That state is not captured as a
version (i.e., in version history) until the VCR is checked in.

> It seems I could implement it such that when a client does
> a CHECKOUT then a PUT then a GET, they see the body that
> existed on the VCR before the checkout.

That would contradict the 'you now GET what you just PUT' expectation
(requirement?) for a content-bearing resource.

> On the other hand, you could implement it so that the same
> client does the same CHECKOUT, PUT and GET, and they see
> the body that they PUT, which is NOT the body that existed
> on the VCR before the checkout.

Yep.  In fact it need not be the same client.  In the example above, other
clients GETting /foo can see all the state transitions of the VCR.

If you, as a client, want to hide these intermediate states for /foo, then
using a working resource would be preferrable.

CHECKOUT the version to create a working resource.
PUT/PROPPATCH etc the working resource.
CHECKIN the working resource to create a new version.
UPDATE /foo to the new version.  This will result in the VCR at /foo having
the same content and dead properties as the new version.

> The deltaV draft needs to pick one or another and make a clear
> requirement.


Tim

Received on Thursday, 8 February 2001 05:33:22 UTC