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?

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!  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.

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.

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

lisa


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of
> Tim_Ellison@uk.ibm.com
> Sent: Wednesday, February 07, 2001 1:21 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Autoversion confusion
>
>
>
>
> > I take your point about the checked-out version only
> > being created when the PUT is issued.  Still, some
> > confusion remains.
>
> Ok, but we are converging!
>
> > The spec frequently makes statements like: "The resource
> > MUST have a DAV:checked-in property that identifies the
> > new version.  The content, dead properties, and DAV:resourcetype
> > of the new version MUST be the same as those of the resource.  "
> > Also: "Although the content and dead properties of a checked-in
> > version-controlled resource are required to be the same as
> > those of its current DAV:checked-in version..."
>
> These statements are made in the context of a checked-in
> version-controlled
> resource.
>
> > OK, so based on my reading of this text and others, I assumed
> > that the VCR ALWAYS had the body and the content of the last
> > checked-in version, whether or not the VCR was checked-out.
>
> No, when a version-controlled resource is checked in it has the same
> content and dead properties (C&DP) as the version identified in the
> DAV:checked-in property.  However, when a version-controlled
> resource is
> checked-out, its C&DP are not necessarily the same as any version.
>
> The moment it is checked out on the server, the VCR will have
> the same C&DP
> as the version identified by the DAV:checked-out property,
> but the nature
> of a checked-out VCR is that it can be modified, so
> subsequent PUTs etc.
> will mean it is no longer the same as the DAV:checked-out version.
>
> Take another look at Section 2.1.2 Modifying a
> Version-Controlled Resource,
> in particular the diagram that shows the VCR moves to state
> S3 after the
> successful PUT.  S3 is not captured as a version until the
> CHECKIN.  Of
> course, there could have been multiple PUTs and/or
> PROPPATCHes between the
> CHECKOUT and CHECKIN.
>
> > Nowhere does the draft state otherwise, e.g. that a checked-out
> > VCR has the body and properties of the checked-out version.
>
> ...because that is untrue.  A VCR is a first-class resource,
> with content
> and properties.  When it is checked out it is "open for
> change".  There is
> no checked-out version associated with a checked-out VCR.
>
> The only way to get a checked-out version is by sending
> CHECKOUT to the
> version itself (i.e., using the version URL, or a Label: header). The
> checked-out version is called a working resource (not a
> checekd-out VCR).
> Creating working resources is optional for the server (the
> "working-resource" option).
>
> > Clearly, you and perhaps the other authors have a different
> > mental model of the way this works, but nowhere in the draft
> > is this stated.  I admit that 2.1.2, on careful viewing, does
> > imply that the checked-out VCR shows the body and properties
> > of the latest version, but I want a normative statement.
>
> A checked-in VCR will always have the same C&DP as the DAV:checked-in
> version.  Sending it CHECKOUT essentially flips a read-only bit to
> read/write (ok and jiggers the live properties a bit) and that's it!
> Simple eh?
>
> Tim
>

Received on Wednesday, 7 February 2001 12:39:14 UTC