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

> > I don't recall hearing of this approach, and don't see how it could
be
> > 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
made
> 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
trying
> > 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
resources.

Lisa