W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Autoversion confusion

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 8 Feb 2001 10:50:15 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569ED.003B9016.00@d06mta07.portsmouth.uk.ibm.com>


Barry wrote:
> 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?

It's worse than that<g>, since
http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001JanMar/0315.html

the options are now:
     DAV:always-checkout-always-checkin
     DAV:always-checkout-when-unlocked-checkin
     DAV:when-locked-checkout
     DAV:never

The names are a description in themselves!  But if you want more read the
updated Section 2.3.5.

> 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:

The autoversion functionality is not explained elsewhere in the spec., so
if it doesn't make sense from what you read then that needs to be fixed.

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

No, LOCK never has had the semantics of hiding updates until the UNLOCK,
and it would be wrong to change its semantics between RFC2518 and DeltaV.

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

The interaction between locking and versioning here is simply to avoid
creating numerous versions of the intermediate states on the basis that
these intermediate states are not 'worthy' of being retained as versions,
but the versioning unaware client has no way of indicating this.  The
DAV:auto-version property states a policy in this respect.


Tim
Received on Thursday, 8 February 2001 05:52:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT