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

If you've deleted the version history, you have effectively
trashed any historical references (e.g. in collection versions)
to that version history.  If you are going to let that deletion
happen even when there is a VCR for that version history in
some workspace, I don't see that it makes any sense to worry
about whether or not the collection containing that VCR is
checked in or checked out.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Friday, June 28, 2002 8:59 AM
To: Clemm, Geoff; ietf-dav-versioning@w3.org
Subject: 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 09:18:59 UTC