RE: UNCHECKOUT after automatic checkout?

Obviously I misunderstood the meaning of "locked-update" in
"DAV:auto-checkin".  See separate mail already sent on the confusion of that
section.

What I'm most interested in is a server that will checkout/checkin if a
client does a PUT outside the context of a lock.  But it will
checkout/checkin only once for a series of PUT requests inside the context
of a lock.  Tim says that would be the case if "DAV:auto-checkin" has a
value of "unlocked-update".

So to confirm:  A client can legally perform this sequence of commands on a
single resource:

1. LOCK version-controlled resource
2. verify that VCR has "locked-update" in DAV:auto-checkout and
"unlocked-update" in DAV:auto-checkin
3. PUT
4. UNCHECKOUT

Other than the confusion over the meaning of DAV:auto-checkin, the spec
ought to say that an automatic checkout can be checked-in or unchecked-out
manually.

Next question reserved for a different mail!

Lisa

>
> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Tim Ellison
> Sent: Thursday, July 12, 2001 3:48 AM
> To: DeltaV
> Subject: 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 12:50:14 UTC