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

Re: UNCHECKOUT after automatic checkout?

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Thu, 12 Jul 2001 11:48:15 +0100
To: "DeltaV" <ietf-dav-versioning@w3.org>
Message-ID: <OF3DDAC0A6.E49C8240-ON80256A87.003A3306@portsmouth.uk.ibm.com>

"Lisa Dusseault" <lisa@xythos.com> wrote:

> Can a client do this sequence of commands to a single resource?
> 1. LOCK version-controlled resource

This would acquire the lock.

> 2. verify that VCR has "locked-update" in DAV:auto-checkout and
> "locked-update" in DAV:auto-checkin


> 3. PUT

Assuming the lock token passed with the request was ok, this PUT
modification request to a locked version-controlled resource would cause:
(1) the resource to be first checked-out, due to DAV:auto-checkout being
(2) the PUT method to be applied,
(3) the resource to be checked-in, due to the resource being auto-checked
out (in step (1)) and DAV:auto-checkin being DAV:locked-update.


The end result is a checked-in version-controlled resource and a new
version resource.


This would fail with a

> Obviously this would have to be a versioning-aware client, relying
> on the auto-checkout and auto-checkin behaviour of the server to do
> the checkout, but able to override the server to cancel the checkout.

If the DAV:auto-checkin had not been DAV:locked-update then the client
could cancel the checkout.

> The advantage of the scenario is that it is fewer commands.  I don't
> see any reason that the spec would not allow this scenario -- I wanted
> to point it out so that server implementors could be sure to test it.

Received on Thursday, 12 July 2001 06:48:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC