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

Geoff,

did you possibly miss the part about the collection "/a" being checked-in?
Otherwise this sounds as if deleting the VHR may have the side effect of
un-version-controlling a resource which is member of a version-controlled
checked-in collection...

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, June 28, 2002 2:43 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: error condition for delete of VHR when VCR is in checked-in
> c ollection
>
>
>
> If you are going to allow deletion of version histories, your best
> bet is to "clean up" (at least, from the protocol perspective).
> This means you should remove all references (or act as if you have
> removed all references) to /vhr/123.  In particular, you would remove
> references from the version-controlled-binding-set of any collection
> version.  The result is that from the perspective of /a, there no longer
> is a version-controlled binding to /a/b, so /a/b is just a
> non-version-controlled member from /a's perspective (i.e. no error).
>
> Cheers,
> Geoff
>
>    From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
>
>    considering:
>
>    - a versioned controlled checked-in collection /a
>    - a version controlled resource /a/b with a version history resource of
>    /vhr/123
>    - a server that handles deletion of version histories as request to
>    un-version-control the VCR
>
>    What should happen upon a DELETE on /vhr/123?
>
>    - this would be considered to change the state of /a/b from being
>    version-controlled to not being version-controlled, however the parent
>    collection isn't checked out
>
>    - returning Conflict with error condition
>    DAV:cannot-modify-checked-in-parent seems to be a valid
> approach, however
>    doesn't fit optimally (because the request was sent to /vhr/123, and /a
> --
>    which causes the error as not bein checked out -- isn't a parent
> collection
>    of the request URI).
>
>

Received on Friday, 28 June 2002 08:59:41 UTC