Re: Autoversion confusion

Given the explainations below, I am led to ask the following question:

Why does Core versioning support both DAV:when-locked and
DAV:when-unlocked for the DAV:auto-version property?

In reading the Core spec (since I am only planning on implementing Core,
I have followed the instruction in Section 1 to only read Sections 1, 2,
and 23, in an effort to see if Core as defined is self contained and a
reasonable set of functionality).  After reading the Core spec, I didn't
understand why these two different types of autoversioning were being
supported (in general the Core spec lacks a lot in the area of
explaining things, many of these may be explained in more detail
elsewhere in the spec, but within the core sections (1, 2, and 23) a lot
of concepts are not explained clearly).  Then after seeing some of the
discussion the last couple days on this list I thought I had it figured
out:

You needed when-locked to provide the equivalent to a working resource
in core.  So a client could make a series of changes that they
considered an atomic unit of work (perhaps a put followed by a
proppatch) and didn't want anyone else to see the changes mid way.  So
they could lock, put, proppatch, unlock and only when they unlocked
would the new version be created and only then would others see the
changes, until then all gets and propfinds would return the information
from the latest checked in version.  But the client/person holding the
lock would see changes to their virtual working resource.  I thought
that this was a great set of functionality for Core versioning.  

But now I see that this isn't the intention for the when-locked flag,
and am left to wonder why it is really needed, or what it's intended
purpose is.

thanks,
--Barry


Tim_Ellison@uk.ibm.com wrote:
> 
> > 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 13:11:00 UTC