checked-out VCC: A new proposal

At the very end of my last response to Tim on this topic,
I proposed an alternative approach instead of "always keep it checked-out".
Since this appeared at the end of a long message, I thought it would
be better to state the new proposal in a separate message (i.e. this one).

To summarize the issue: In order to allow a baseline-unaware
versioning client to interoperate with version-controlled resources
that are under baseline control, it is important to allow a client to
to check-out/check-in any version-controlled member of a
baseline-controlled collection.  My previous proposal to address this
is to require that a version-controlled configuration is always in the
checked-out state.  One can make a good argument for why there is
little/no value in having the version-controlled configuration ever be
in the checked-in state, but rather than make that argument, I believe
there is an alternative that provides a more regular model, and that will
be more palatable to those who have objected to the "it's always
checked-out" approach.

The new proposal is to add a new value for the DAV:auto-version
property, namely the "DAV:always-checkout" value.  When this value is
set for a checked-in version-controlled resource, that resource will
automatically be checked out whenever it is updated, but must be
explicitly checked in (with a subsequent CHECKIN request) to create
a new version (or in the case of a configuration, to create a new
baseline).

This addresses the baseline-unaware versioning client issue, because
a baselining server that wants to be friendly to such a client will
set the DAV:autoversion property of a version-controlled configuration
to be DAV:always-checkout.  Standard checked-out/checked-in semantics
will then apply to the version-controlled configuration.

Any objections?

Cheers,
Geoff

Received on Thursday, 12 April 2001 10:56:09 UTC