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

Geoff,

thanks for taking the time to look into these issues...

> From: [email protected]
> [mailto:[email protected]]On Behalf Of Clemm, Geoff
> Sent: Tuesday, July 09, 2002 12:27 AM
> To: [email protected]
> Subject: RE: error condition for delete of VHR when VCR is in checked-in
> c ollection
>
>
>
>
>    From: Julian Reschke [mailto:[email protected]]
>
>    > From: Clemm, Geoff
>    >
>    > If you've deleted the version history, you have effectively
>    > trashed any historical references (e.g. in collection versions)
>    > to that version history.
>
>    Nope. I have deleted the binding to the version history, not
>    necessarily the information itself. In particular, my server may be
>    able to reconstruct it upon UNCHECKOUT of the versioned collection
>    "/a" (using the same URI).
>
> I'm not sure how an UNCHECKOUT of a VCCl is related to this thread,
> since an UNCHECKOUT request has no effect on a version history
> resource.  But in any case, postcondition DAV:delete-version-set in
> Section 5.6 states that deleting a version history resource deletes
> all versions in that version history.  So your server would not be
> able to reconstruct the version history once it was deleted.  Note
> that the errata issue 14_DIFFERENT_VH_DELETION_SEMANTICS_REQUIRED
> clarifies that deleting a member of a working collection just removes
> a binding to a VHR, but doesn't delete the VHR.

My theories goes like this :-)

- by checking in a VCC that contains a VCR member, I am effectively creating
a new binding to the VHR of this VCR member. This binding may not be visible
in my "public" URL namespace, but it's still there
- a subsequent delete on the VHR URL just deletes the original binding to
the VHR, but the version history resource (and the versions inside the
version history) is not affected
- thus, upon UNCHECKOUT of the VCC, I can reconstruct the VHR (re-creating
the original binding)

Maybe these problems go away when we remove connection between deleting the
VHR and un-versioning a resource, but this is how it looks right now.

>    > 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.
>
>    The issue is that RFC3253 doesn't define a method to switch off
>    version control on a resource, and therefore people are using
>    deletion on VHRs to switch off versioning (I couldn't find any
>    mention of this in the spec, though).
>
> 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.

>    This conflates to separate things, but there doesn't seem to be
>    better way to do it (please don't say COPY/DELETE/MOVE, because
>    this creates a *new* 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.

However, I now have a new question:

If - after the deletion of a VCR's VHR - the VCR is still
version-controlled - where does it's DAV:version-history property point to?
Similarily, if the delete of the VHR deleted all versions, where does
DAV:checked-in/DAV:checked-out point to?

-> Seems that we need to clarify the post-conditions for deletions of VHRs,
right?




[1]
<http://www.sharemation.com/~milele/public/dav/draft-dusseault-deltav-subset
-00.txt>