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

Ok.

> 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
DAV:locked-update,
(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.

(i.e. CHECKOUT, PUT, CHECKIN)

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

> 4. UNCHECKOUT

This would fail with a
<DAV:must-be-checked-out-version-controlled-resource>


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


Regards,
Tim
Received on Thursday, 12 July 2001 06:48:31 GMT

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