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

RE: COPY, MOVE and VCR's

From: <gclemm@rational.com>
Date: Thu, 24 Jan 2002 12:28:50 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AEFF@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Peter Raymond [mailto:Peter.Raymond@merant.com]

   [Daniel said:] 
   >For COPY I'd expect to got a new VCR at the destination with an
   >exact copy of properties. This implies that the new created VCR
   >must share the version-history with the source VCR. Is this
   >correct? Is this desirable?

   I think this is desirable and correct but with one caveat... 

Well, one can debate whether or not it is desirable, but it definitely
is not correct.  COPY does not create a new VCR, unless the server
automatically puts all new resources under version control, and in
that case, a new version history will be created for it.

   Both in section 1.3 (where the workspace term is defined) and in
   section 6 the DeltaV specification says that you can only have one
   VCR for a given version history in a workspace.  If copy created a
   new VCR but pointed to the original VHR then this rule could be
   violated if the destination is in the same workspace as the source
   of the copy.  If the copy does not break this rule then it would be
   fine to have two VCRs pointing to the same version history.

Yes, but you need to use the VERSION-CONTROl request (identifying
a version) to make this be the case, not a COPY.

   I certainly wouldn't have thought that moving a VCR would create a
   new history resource.

That is correct.  A MOVE is very different from a COPY, since it
effectively just renames the resource, but otherwise leaves it
unmodified.

Cheers,
Geoff
Received on Thursday, 24 January 2002 12:30:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT