Some WebDAV methods behave differently on servers supporting Delta V. 11.5.1 DELETEDELETE operations are special in versioning systems. Many systems do not allow versions or VCRs to be deleted, because it must always be possible to recover past state. It must be possible to remove a resource from a collection, even if this action doesn't destroy the resource content. Thus, DeltaV allows the DELETE method to delete a checked-in VCR, but this does not destroy all the saved versions that are related to the resource.
DeltaV needs a way to access versions of deleted resources. Recall that you can use the VCR URL to discover a set of versions by asking the server for a version-tree report. However, when the VCR is deleted, the versions still exist and there must be some way to be access them. A new kind of resource type was introduced to serve as a gateway: A version-history resource (VHR) is a permanent resource with a permanent link to a set of versions. The VHR is created as soon as a VCR is created, and it continues to exist after the VCR is deleted. VHRs exist in a special collection, with URLs chosen by the server. The server publishes the URLs to the VHR collections in the body of a special OPTIONS response (see Section 11.10.3), so the client can discover VHRs by using PROPFIND to browse those collections. There are three ways to discover the URL of a VHR:
VHR support is not mandatory. On systems that don't support VHRs, a DELETE (if permitted) is permanent and the versions are no longer available. Some systems may even allow individual versions to be deleted. 11.5.2 Version History ResourcesVHRs were introduced in the previous section and are defined more completely here. VHRs have their own URLs, separate from all VCRs. These URLs all exist in VHR collections, and clients may be prevented from creating regular resources in those collections. A VHR is created whenever an existing resource is put under version control. The server automatically assigns a URL to the new VHR. A VHR must exist for each VCR. The VHR is truly a new kind of resource its resource type is <DAV:version-history>. A VHR has no body, but it has a number of properties that link to versions. In fact, much of the specification of VHRs involves how to find the URL to one kind of resource given another kind of resource.
Note that DeltaV defines no way to go straight from the version URL to the VCR URL. That's because the core DeltaV model must be compatible with the advanced DeltaV model, including features like workspaces (Section 12.2). Workspaces introduce a way for multiple VCRs to share the same versions and version history, so DeltaV does not require the server to link each version back to all those VCRs (see Figure 11-6). Figure 11-6. VHR and relationships to other resources.11.5.3 COPYThe COPY method existed before DeltaV, but DeltaV adds some new concerns. First, we'll discuss what happens to the version history if the source or the destination is a VCR. How should COPY work? The desired behavior for COPY is clearest when the source is a regular resource and the destination is a VCR with an associated version history. Clearly, the server should not overwrite the destination and its entire history with the single body of a regular resource. What if the source resource was just a template or a file in a contributions folder? The user probably intended the source content to overwrite only the latest version of the destination. Thus, the model for COPY behavior is that the result should be the same if the client did a GET and PROPFIND of dead properties, followed by PUT and PROPPATCH to the new location. That model leads to the following behavior (see Table 11-1), with the caveat that if the Overwrite header on the request has the value F and the destination exists in any form, the request must be failed. Because the destination is altered in a COPY operation, if the destination is a VCR it may have to be checked out first. A new version may be created immediately if the COPY destination is a VCR with auto-versioning (see Section 11.6.2). The new version may be created later if the destination is a checked-out VCR which is later checked in. The request will fail if the destination is checked in and auto-versioning is off.
DeltaV doesn't specify what to do if the client sends the Overwrite: F header on a COPY request when the destination is a VCR. One could imagine two ways to interpret this:
For the sake of the non-DeltaV client and for consistency with MOVE when the destination is a VCR, I recommend that servers use the second option and fail the request. However, since this isn't specified in the standard, there is no way for the client to rely on this behavior. Unfortunately, the client has no real workarounds here. There are no conditional headers that would allow the client to insist that if the destination exists already, the COPY must fail. Thus, the burden on the server to do the right thing is even heavier. The source of a COPY request may be a version, but the destination may not be. A VHR may not be either the source or the destination of a COPY. 11.5.4 MOVEMOVE is even more difficult than COPY because both the source and the destination are modified. The definition must include what happens to the version history at the source (if the source is a VCR) as well as the version history at the destination. The rename scenario makes the desired behavior of MOVE most obvious. Clearly, if a client is using MOVE to rename a VCR (the source is a VCR and the destination does not exist), the result of the operation must be a VCR with the same version history, contents, and properties but a new URL. DeltaV specifies this by saying that a MOVE must be applied by doing a depth infinity DELETE operation on the destination first. To apply that definition to the case where the destination is a VCR as well, we can see that the destination is completely replaced by the source. The original destination version history may still be available (if the server supports VHRs), but the destination URL no longer links to it. DeltaV does not require either the source or the destination to be checked out prior to a MOVE request, so the server should be able to handle each case. If the source of the MOVE is checked out prior to the MOVE, then it should remain in that state after the operation (see Table 11-2).
If the Overwrite header is false and any resource exists at the destination, the request is failed. Because version histories at the destination can be lost if a destination VCR is overwritten, client implementors should be cautious in issuing MOVE operations of this kind. The client software could present a warning to the user or not allow the operation at all unless the user is willing to explicitly delete the destination first. The server could also reject MOVE requests when the destination has a version history, but there is no specific error code to use to indicate why the operation is forbidden. Neither the source nor the destination of a MOVE request may be a version or a VHR. |