W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2000

RE: COPY semantics

From: Clemm, Geoff <gclemm@Rational.Com>
Date: Tue, 4 Apr 2000 09:59:36 -0400
Message-ID: <65B141FB11CCD211825700A0C9D609BC025F9B37@chef.lex.rational.com>
To: w3c-dist-auth@w3c.org
I agree with Jim.  When a COPY is applied to a revision
or a working resource, it has the same semantics as if it
were applied to an unversioned resource of that type.
When the Target-Selector:metadata header is used, I
believe the COPY MUST fail, because it is not feasible
to COPY all the versioning metadata relationships
(such as activity and baseline membership).

Any objections?


-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Monday, April 03, 2000 5:29 PM
To: w3c-dist-auth@w3c.org
Subject: Re: COPY semantics

COPY has to depend on what you requested to copy. If its a working
resource, you should get a new, unversioned resource. If its a revision,
you should get a new unversioned resource of that revision. If its a
versioned resource, you should probably get the whole history. But that
maybe we should dissallow copy on versioned resources?

|        |          "Tim Ellison/OTT/OTI"   |
|        |          <Tim_Ellison@oti.com>   |
|        |          Sent by:                |
|        |          ietf-dav-versioning-requ|
|        |          est@w3.org              |
|        |                                  |
|        |                                  |
|        |          04/03/2000 03:15 PM     |
|        |                                  |
  |                                                                     |
  |       To:     ietf-dav-versioning@w3.org                            |
  |       cc:                                                           |
  |       Subject:     COPY semantics                                   |

(I've posed this question before, but it didn't get much discussion...)

What does COPY mean for a versioned resource?

Options might be:
(1) create a new versioned resource at the destination whose initial
revision is the same as the revision selected by the source,
(2) copy all the history of the source to a new versioned resource at the
(3) make a new unversioned resource that has looks like the selected source
(i.e., looses it's versioned status).

Then how does that differ if the selected resource is a working resource?
We disallow a working resource without a corresponding versioned resource
with at least an initial revision.
Option (1) seems the most likely candidate to me.

Received on Tuesday, 4 April 2000 10:02:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC