- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 19 Aug 2001 00:42:23 -0400
- To: DeltaV <ietf-dav-versioning@w3.org>
From: Lisa Dusseault [mailto:lisa@xythos.com] At the DeltaV meeting in London, we discussed how to make a resource unversioned. We determined that the current method currently proposed in section 2.2.1 of draft 16 (COPY the latest version of the resource to a new location, then DELETE the old versioned resource, then MOVE to rename the new unversioned resource to the old name) is broken The conclusion reached at the DeltaV meeting was not that this method was broken, but rather that although there would be some benefits to an explicit UNVERSION-CONTROL method (such as the ones Lisa identifies in her message), there was not sufficient support for this new method within the working group to add it to the protocol. The UNVERSION-CONTROL method is just one of many possibly useful features that did not receive sufficient support to be added at this point. When the DeltaV protocol goes from proposed standard to draft standard, there will be an opportunity to pick up new features that have proven to be needed, and drop features that have proven to not be needed. The recent consensus has been that the protocol is sufficiently complex that it is appropriate to defer any new feature that does not conflict with existing semantics (i.e. a new feature that can subsequently be added without conflicting with what is currently defined in the protocol). We discussed replacing that with the recommendation "delete the VHR to remove a resource from version control". However it also has weaknesses, some of which I didn't remember quickly enough to bring up in the meeting: - it could break situations where more than one VCR points to the same VHR, a scenario which has specifically been discussed as being permitted by DeltaV. Would it make all those VCRs no longer versioned? Yes, this problem was raised in followup discussions following the working group meeting. A server could reasonably refuse to allow the deletion of a version history in this case, remove all of those VCR's from version control, or leave them all dangling. Following those discussions, it was concluded that the "delete version history" was not an appropriate way to remove a resource from version control, and therefore the method that is described in the current protocol (COPY to temp, MOVE to original URL) is the best way to achieve this result in the current protocol. Cheers, Geoff
Received on Sunday, 19 August 2001 00:54:42 UTC