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

RE: error condition for delete of VHR when VCR is in checked-in c ollection

From: Lisa Dusseault <ldusseault@xythos.com>
Date: Tue, 9 Jul 2002 12:46:11 -0400
Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BA9@ATL1VEXC006.usdom004.tco.tc>
To: "Julian Reschke" <julian.reschke@greenbytes.de>, "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>

> > I don't recall hearing of this approach, and don't see how it could
> > compatible with the spec, giving the DAV:delete-version-set
> > postcondition.
> OK. It was originally suggested in section 4.2 of
> draft-dusseault-deltav-subset-00 [1], and up until some time ago, it
> a
> lot of sense to me.

FYI, I too have decided it is not a super idea to use DELETE of a VHR to
turn off versioning (though it's better than COPY/MOVE/DELETE). I still
believe some straightforward mechanism is needed to turn off versioning
for a resource.

> > COPY/DELETE/MOVE is the only interoperable way of removing something
> > from version control.  If you need a mechanism that doesn't create a
> > new resource, I'd suggest something like allowing a PROPPATCH to
> > remove the DAV:version-history property of the VCR, rather than
> > anything related to VHR deletion.
> Sounds good, and we'll look into this.

No, this is an even worse idea, and has been discussed before. 
1.  The COPY creates a new resource with a new creation date, owner,
etc. This is NOT the same as modifying an existing resource so that it
is no longer version-controlled.  It involves creating a new resource,
which may mean different access control settings inherited from the
parent, etc.
2.  If the server automatically does VERSION-CONTROL, then the client
ends up with TWO version-controlled resources, when it wanted zero. Now
the client has to clean up a mess.

As long as it is possible to turn a non-versioning resource into a
versioned resource with VERSION-CONTROL, it should be possible to do the
reverse operation in a way that doesn't involve the creation of new

Received on Tuesday, 9 July 2002 12:47:27 UTC

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