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: Julian Reschke <julian.reschke@greenbytes.de>
Date: Tue, 9 Jul 2002 18:51:10 +0200
To: <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEKKEOAA.julian.reschke@greenbytes.de>

> From: Lisa Dusseault [mailto:ldusseault@xythos.com]
> Sent: Tuesday, July 09, 2002 6:46 PM
> To: Julian Reschke; Clemm, Geoff; ietf-dav-versioning@w3.org
> 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.
Received on Tuesday, 9 July 2002 12:52:12 GMT

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