- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 21 May 2001 09:11:59 -0400
- To: ietf-dav-versioning@w3.org
From: Fay, Chuck [mailto:CFay@filenet.com] > From: Clemm, Geoff [mailto:gclemm@rational.com] > .... Now it is true that if auto-checkout=locked-update is not > set, then a locked resource would never have been automatically > checked out, but this doesn't change/affect the meaning of > auto-checkin=locked-update. That was my underlying concern about the two-property approach: there are combinations of settings for auto-checkout and auto-checkin that produce odd results, or are just dysfunctional (as in the above example). So in that sense, the use of these two properties is not as well-defined as auto-version was. I don't believe this behavior is any more odd or dysfunctional than the fact that CHECKIN fails if it is applied to a resource that is not checked in, or that UNLOCK fails if it is applied to a resource that is not locked. I'll leave it up to the list as to whether this is a problem. It can certainly be avoided by using only combinations that match the old settings for auto-version. I agree. My take on the mapping: never: auto-checkout = not set auto-checkin = not set always-checkout-always-checkin: auto-checkout = locked-update, unlocked-update auto-checkin = locked-update, unlocked-update always-checkout-when-unlocked-checkin: auto-checkout = locked-update, unlocked-update auto-checkin = unlocked-update when-locked-checkout: auto-checkout = locked-update auto-checkin = unlocked-update You could also just leave auto-checkin unset in this case, since the DAV:auto-checkout indicates that unlocked resource will not be automatically checked out, but setting it to DAV:unlocked-update is fine too. always-checkout-manual-checkin: auto-checkout = locked-update, unlocked-update auto-checkin = not set > If a write-locked version-controlled resource was automatically > checked out because the DAV:auto-checkout property was > DAV:locked-update, and if the resource was still checked-out when the > write lock is removed (such as from an UNLOCK or lock timeout), then > the removal of the write lock is automatically preceded by a checkin > operation. This doesn't seem sufficient. It would imply that "auto-checkin = not set" would cause an automatic checkin when the write lock is removed. I don't think this is what you intended. That's why I included the specific setting of auto-checkin in my suggested wording. Actually, that was what I intended, i.e. if an auto-checked-out resource is unlocked, it is automatically checked in before the unlock (independent of the current settings of DAV:auto-checkin). But one could make a case to allow this to be explicitly specified in the DAV:auto-checkin setting, i.e. add a "DAV:unlock" value for DAV:auto-checkin, and only do the auto-checkin on UNLOCK if this value is set. This also makes this behavior more explicit. Any votes on whether we keep it the way it is, or whether we add an explicit DAV:unlock value to DAV:auto-checkin? Cheers, Geoff
Received on Monday, 21 May 2001 09:12:43 UTC