RE: COPY semantics

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?

Cheers,
Geoff

-----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
destination,
(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.

Tim

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