W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002


From: <gclemm@rational.com>
Date: Thu, 24 Jan 2002 12:23:50 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AEFE@SUS-MA1IT01>
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
   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.

Received on Thursday, 24 January 2002 12:24:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC