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

RE: Making resources unversioned

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 19 Aug 2001 00:42:23 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F48F89@SUS-MA1IT01>
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

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.

Received on Sunday, 19 August 2001 00:54:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC