RE: auto-checkout and auto-checkin

Well, I intended "! Checkin-Locked" to mean that the value of
auto-checkin did not include locked-update.


However, it seems though I've been burned again.  I assumed that
<auto-checkin><locked-update/></auto-checkin> meant something completely
different that it does.

So it would seem that my server supports:
<auto-checkout><unlocked-update/><locked-update/></auto-checkout>
And
<auto-checkin><unlocked-update/></auto-checkin>

And the logic is thus:
PUT on a VCR Entry:
If the VCR is checked in AND no workking-resource has been created (no
forking, remember) then check it out, else fail.
If you just checked it out, remember that you did an 'AUTO' checkout,
and remember whether the resource was locked when
You did so.

... Do the PUT ...

PUT on a VCR Exit:
If you just did an AUTO checkout and the resource isn't locked then
check it in.

UNLOCK or Lock Expire:
If an AUTO checkout was done, and the resource was locked when it was
done, then do a checkin.

 




> -----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 4:31 AM
> To: 'DeltaV'
> Subject: RE: auto-checkout and auto-checkin
> 
> 
> 
> "John Hall" <johnhall@evergo.net> wrote:
> 
> > Well, a server is free to freeze these values.  The server doesn't 
> > have to let the client muck with them, and if it does allow 
> the client 
> > to muck with them I assume it could enforce whatever 
> combinations it 
> > deems reasonable.
> 
> Yes, definitely.
> 
> > Consider PUT.
> >
> > The code becomes:
> > putEntryStuff();
> > doPut()
> > putExitStuff();
> >
> > Where putEntryStuff will throw an exception if the PUT is
> > not allowed.
> >
> > Checkout-Locked, Checkin-Locked:
> > Lock, Put, Unlocked is the expected behavior.  Though Lock, Put, 
> > CheckIn and Lock, Put, Uncheckout behave just-as-if the client had 
> > done an explicit checkout before the Put.
> 
> Assuming you start with an unlocked version-controlled resource...
> LOCK, PUT, CHECKIN      and
> LOCK, PUT, UNCHECKOUT
> Will both fail because the resource will already be 
> auto-checked-in after the PUT.
> 
> > Checkout-unlocked and Checkin-unlocked imply and atomic operation.
> > 'PUT' becomes equivalent to
> > CHECKOUT, PUT, CHECKIN.
> 
> Yes (assuming the version-controlled resource is checked-in 
> and not locked).
> 
> > OK:
> > Checkout-Locked, ! Checkin-Locked:
> > Lock, Put -- is the same as LOCK, CHECKOUT, PUT and the system 
> > requires an explicit CHECKIN.
> 
> What does !checkin-locked mean?  do you mean checkin-unlocked (a.k.a.
> DAV:unlocked-update) or that it has no value?
> 
> > Checkout-Unlocked, ! Checkin-Unlocked:
> > PUT is CHECKIN, PUT and the resource is left in exactly
> > that state.
> 
> Sorry, your notation is lost on me -- please can you restate it.
> 
> > ! Checkout-Locked, Checkin-Locked:
> > Now I really don't like this combination.  It introduces nastiness 
> > like "CHECKOUT, PUT, LOCK, UNLOCK", with the spec potentially
> > implying that the UNLOCK would require a CHECKIN.  It is
> > OK if this state is explicitly ruled illegal, or if the
> > Checkin-Locked is defined so that it ONLY comes into play
> > if the CHECKOUT was done because of a Checkout-Locked
> > action.
> >
> > ! Checkout-Unlocked, Checkin-Unlocked:
> > CHECKOUT, PUT becomes CHECKOUT, PUT, UNCHECKOUT.  That doesn't make 
> > sense to me, but I was planning on supporting it.  Note that it 
> > doesn't require a separate test case if putEntryStuff leaves the 
> > object in the correct internal state.
> >
> > ============================
> >
> > Of the 8 possible states, 4 are 'obvious' 3 are 'funny' and 1 is a 
> > really bad idea.  If you retained the current discription (since I 
> > think it might be easier to describe things the current 
> way) but added 
> > the restriction that auto-checkin must be the same value as 
> > auto-checkout that would be OK with me.
> 
> There's quite a list, you have to consider the initial 
> version-controlled resource being locked or unlocked and 
> checked-in or checked-out together with the combination of 
> valid values (which are DAV:locked-update, 
> DAV:unlocked-update, both, or none).
> 
> I recall Jim W. wrote out the table a while ago (sorry I 
> can't go and look for it right now).
> 
> Regards,
> Tim
> 
>

Received on Thursday, 12 July 2001 12:35:13 UTC