- From: <gclemm@rational.com>
- Date: Thu, 24 Jan 2002 12:23:50 -0500
- To: ietf-dav-versioning@w3.org
From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com] I wonder what happens when I copy or move a VCR? See section 3.14 (Additional COPY Semantics) and section 3.15 (Additional MOVE Semantics). For COPY I'd expect to got a new VCR at the destination with an exact copy of properties. No. See the DAV:must-not-copy-versioning-property postcondition defined in 3.14. Versioning properties are not copied by COPY. The resource created by the COPY is the same as would be created by a GET/PROPFIND(dead properties)/PUT/PROPPATCH combination (i.e. it is not version-controlled, unless the server automatically puts all resources under version control, and in the latter case, a new version history is created for the new resource). This implies that the new created VCR must share the version-history with the source VCR. No, this would never be the case. Is this correct? Is this desireable? No, and no. Defining this behavior as not expected by the user, I'd say COPY means creation of a new version-history and copy of the checked-in version to that new VH. With that the checked-in property of the copied VCR must change. Close. COPY of a VCR creates a new resource whose content and dead properties are the same as the source for the COPY. A new version history is created only if the server automatically puts every new resource (such as the result of a PUT) under version control. In this case, the checked-in property is guaranteed to be different. Same for MOVE except for the deletion of the source. No, MOVE is totally different. A MOVE is just a "rename", so the resource (including all its versioning properties) remain the same, but it is now mapped to a new URL. See section 3.15. Cheers, Geoff
Received on Thursday, 24 January 2002 12:24:53 UTC