Allowing non-default options for auto-checkout and -checkin

I'm following up on this discussion from 

http://lists.w3.org/Archives/Public/ietf-dav-versioning/2001OctDec/0021.html

in a separate thread. Would it be appropriate to
consider part of these changes in the editorial pass
for the initial RFC?


I wrote:

   - Autoversioning (extension), baseline feature (use
     case): In Section 3.2.2, change the EMPTY elements
     in the DAV:auto-version property values to ANY,
     enabling DAV:checkin and DAV:checkout elements
     with default checkin and checkout options for the
     autoversioned VCR to be applied at auto-checkin
     and auto-checkout time. Use case: multiple
     workspaces share the same DAV:current-activity-set
     and the same DAV:checked-in baselines for their
     version-controlled configurations, and those VCCs'
     DAV:auto-version properties are
     DAV:checkout. There is a problem because
     baseline-controlled members of those workspaces
     cannot be checked in even if they are for
     different version histories - only the first
     workspace can auto-checkout its VCC unreserved in
     the shared DAV:current-activity-set.

Geoff replied:

     That sounds pretty reasonable to me.  I might just
     give these their own property names though, so
     that it is easier for a client to determine if
     this option is supported.

-- 

Continuing this discussion, is there a possibility that
some of the following changes might be made in the first
RFC?

   - In Section 3.2.2, change the EMPTY elements in the
     DAV:auto-version property values to ANY to enable
     better extensibility of those property
     values. 

     (The extension I have in mind is to include a
     DAV:checkout or DAV:checkin element within the
     DAV:auto-version property value to allow options
     to be specified in auto-checkout and auto-checkin
     operations.)

  or, 

   - Around Section 3.2.2, define additional property
     names to hold options for auto-checkout and
     auto-checkin operations.


Here is my use case in more detail.

Multiple users want to collaborate fairly closely on
changes to an existing set of resources, but they still
want some isolation. Their DeltaV server supports the
advanced server workspace package. The users' editing
clients only support the basic server workspace
package, but they also have an advanced versioning
"helper" client to perform workspace setup tasks.

The users make their edits in separate workspaces to
gain some degree of isolation. They start working from
the same starting point. This is implemented by
initially putting the workspaces under the control of
the same baseline(s). Because the users wish to
collaborate closely, they work in the same activity to
avoid performing logical content merging among
themselves.

An advanced versioning "helper" client sets up the
users' workspaces by setting up the initial state of
their baseline-controlled collections and
DAV:current-activity-set property values. This helper
client can also import other users' checkins from the
shared activity into each workspace by requesting a
MERGE from that activity into the workspace with the
activity checkin parameter turned off.

To allow the users' editing clients, which understand
the basic server workspace package, but not the
advanced features, to checkin baseline-controlled
workspace members, those baselines' version-controlled
configurations' DAV:auto-version property values are
DAV:checkout.

This is where I run into trouble if there is no way to
deviate from the default options for checkout and
checkin when they happen during autoversioning. When
the first checkin request for a baseline-controlled
workspace member is processed, its version-controlled
configuration is automatically checked out by
autoversioning. This checkout occurs in the workspace's
(shared) DAV:current-activity-set, and 13.10 seems to
imply that the checkout should be the reserved
default. Now, when a second workspace also processes a
checkin request for a member under the control of the
same baseline, the server will attempt an auto-checkout
for the second workspace's version-controlled
configuration in the same shared activity. Unless the
auto-checkout is allowed be unreserved instead of the
reserved default, this second auto-checkout MUST fail
by precondition
DAV:one-checkout-per-activity-per-history in 13.10.

Roy

Received on Sunday, 7 October 2001 13:01:50 UTC