- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 12 Apr 2001 10:57:41 -0400
- To: ietf-dav-versioning@w3.org
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