RE: checked-out VCC: A new proposal

> From: Clemm, Geoff [mailto:gclemm@rational.com]
> Sent: Tuesday, April 17, 2001 8:35 PM
>
>    From: Fay, Chuck [mailto:CFay@filenet.com]
> 
>    Overall, I prefer the previous DAV:auto-version property and its
>    settings, because the four possible settings were all well-defined.
>    With the proposed property tuple (DAV:auto-checkout,
>    DAV:auto-checkin) replacing DAV:auto-version, there appear to be
>    thirty-two possible settings of the tuple.
> 
> Actually, the four possible values:
>  auto-checkout=unlocked-update
>  auto-checkout=locked-update
>  auto-checkin=unlocked-update
>  auto-checkin=locked-update
> are independent of each other, so there are no combinatorics involved
> here.
> 
> Also, separating it into two (independent) properties made the
> writeup much simpler (especially when I needed to add a 5'th
> alternative to DAV:auto-version).

I'm not sure I buy this completely, when the behavior of auto-checkin is
defined conditionally based on auto-checkout.  ("If a write-locked
version-controlled resource was automatically checked out because the
DAV:auto-checkout property was DAV:locked-update, ...")

>    Specific issues with the tuple proposal:
> 
>    1. It's not clear to me how the server should behave for some of
>    the settings for (DAV:auto-checkout, DAV:auto-checkin), such as
>    (DAV:unlocked-update, DAV:locked-update) or (not set,
>    DAV:locked-update and/or DAV:unlocked-update).
> 
> The behavior of the server with one value is set is independent of its
> behavior when another value is set (which is why there is no
> combinatorics here).
> 
> In particular, auto-checkout=unlocked-update means that when you
> update an unlocked (checked-in, version-controlled) resource, it is
> automatically checked out before the update.  The value of
> auto-checkin has no effect on this behavior.
> 
> Analagously, auto-checkin=locked-update says that when you update a
> locked (checked-in, version-controlled) resource, it is automatically
> checked in if it was automatically checked out for the update.  This
> behavior is independent of the value of auto-checkout.  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.

Perhaps the setting of auto-checkout doesn't change the meaning of
auto-checkin, but it does affect the behavior associated with the
auto-checkin settings, as you noted above.  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'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.  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

always-checkout-manual-checkin:
    auto-checkout = locked-update, unlocked-update
    auto-checkin  = not set

>    3. The description of the checkin-on-unlock operation doesn't seem
>       complete.
> 
>    Geoff Clemm wrote:
>    > If a write-locked version-controlled resource was automatically
>    > checked out because the DAV:auto-checkout property was
>    > DAV:locked-update, a removal of the write lock (such as from an
>    > UNLOCK or lock timeout) is automatically preceded by a checkin
>    > operation.
> 
>    Another clause concerning the setting of DAV:auto-checkin seems
>    necessary to make the above statement true:
> 
>    "If a write-locked version-controlled resource was automatically
>    checked out because the DAV:auto-checkout property was
>    DAV:locked-update, and the DAV:auto-checkin property is
>    DAV:unlocked-update and not DAV:locked-update, a subsequent removal
>    of the write lock (such as from an UNLOCK or lock timeout) is
>    automatically preceded by a checkin operation."
> 
> Good point!  How about the following phrasing though:
> 
> 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.

--Chuck

Received on Thursday, 19 April 2001 15:16:49 UTC