W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

Making resources unversioned

From: Lisa Dusseault <lisa@xythos.com>
Date: Fri, 17 Aug 2001 22:27:31 -0700
To: "DeltaV" <ietf-dav-versioning@w3.org>
Message-ID: <HPELJFCBPHIPBEJDHKGKIEHICLAA.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, for the following
reasons:
 - It's not guaranteed to work, but not guaranteed to fail if it doesn't
work.
   E.g. the server might automatically create a new versioned resource.  No
way for the client to tell in advance.
 - Log files, permissions, etc. are lost in this series of moves
 - Permissions could prevent the completion of this sequence of events and
leave the documents in a poor intermediate state.  With a single request, a
permissions failure leaves the client in the same state as it was before it
started.
 - basically, it's a side-effect, not a designed behaviour, and relies on
several non-atomic operations working together

We discussed replacing that with the recommendation "delete the VHR to
remove a resource from version control".  This has fewer problems because
it's at least a single atomic request.  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?
 - it requires clients and particularly servers to support an entire
optional chapter of DeltaV, and a new resource type with all its live
properties, just to get the ability to remove a resource from version
control.
 - the spec would have to deal with the order of delete operations.  To
delete a resource and all its versions, must the client delete the VHR first
then the now-recently-unversioned resource?  Is deleting the VCR when the
VHR still exists forbidden?

A specific syntax for making something unversioned is still the cleanest way
to go, because when you design a specific syntax for a specific job you're
more likely to be able to make it work.  But in the absence of that, the
draft should at least be brought up-to-date with the most current
VHR-deleting recommendation.

lisa
Received on Saturday, 18 August 2001 01:27:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT