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

> From: Lisa Dusseault [mailto:[email protected]]
> Sent: Tuesday, July 09, 2002 6:46 PM
> To: Julian Reschke; Clemm, Geoff; [email protected]
> Subject: RE: error condition for delete of VHR when VCR is in checked-in
> c ollection
> 
> ...
>
> > > 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.

Nobody was proposing COPY (this time),

> 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.

Agreed.