Re: UNCHECKOUT after automatic checkout?

"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 UTC