W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1998

RE: Copy/Move as they relate to versioned resources

From: Chris Kaler <ckaler@microsoft.com>
Date: Mon, 30 Nov 1998 11:18:41 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757930@RED-MSG-52>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, BCragun.ORM2-1.OREM2@gw.novell.com
Cc: w3c-dist-auth@w3.org, MMahoney.ORM3-1.OREM3@gw.novell.com

No we haven't specified the exact behavior (but we need to).  My assumption
has always been that a move would fail and a copy would succeed.  I think
you can do this either using the revision-specific URL or by specifying a
Revision-Id header.

I think that in some cases a new versioned resource might be created.  For
example, copying from one workspace configuration to another might create a
new versioned resource.  I think of the workspace configurations as distinct
from one another.

Chirs

		-----Original Message-----
		From:	Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
		Sent:	Tuesday, November 24, 1998 7:49 PM
		To:	BCragun.ORM2-1.OREM2@gw.novell.com
		Cc:	w3c-dist-auth@w3.org;
MMahoney.ORM3-1.OREM3@gw.novell.com
		Subject:	Re: Copy/Move as they relate to versioned
resources

		   Date: Tue, 24 Nov 1998 15:05:16 -0700
		   From: "Bruce Cragun" <BCragun.ORM2-1.OREM2@gw.novell.com>

		   Do we state specifically the behavior of COPY and MOVE
when acting on
		   a versioned resource versus behavior when acting on a
revision?

		I believe not.

		   As an
		   example, if versioned resource A has three revisions,
each revision
		   has its own unique URL.

		At least one, yes.

		   If I perform a COPY or MOVE using the URL
		   for, say, the second revision, does that just copy or
move that
		   specific revision?

		The "MOVE" should fail (otherwise you've rewritten history
in some
		bizarre fashion).  Note that a "MOVE" of a *reference* to a
revision
		(which is what appears in a "workspace") just moves that
reference
		from one collection to another, and has no effect on the
underlying
		revision or its versioned resource.

		The COPY just acts like a normal COPY of one (non-versioned)
resource
		to another.

		   If so, does that create a new versioned resource?

		No.

		   And if the operation was a MOVE, is that revision no
longer a revision
		   in the source revision set?

		If we make MOVE fail, we don't have to answer this question.
		Note that a DELETE on a revision is allowed (although the
underlying
		CM engine must be allowed to refuse to carry out the DELETE,
if it
		doesn't believe in changing history).

		   Also, my understanding is that each versioned resource
will have a
		   unique URL as well as each revision of that versioned
resource having
		   its own URL.  Is that everyone's understanding?

		That certainly is mine, and certainly is my understanding of
the
		agreement we reached at the last design meeting.

		   If so, and I use the
		   URL of the versioned resource in a MOVE or COPY, does
that move or
		   copy the entire versioned resource or do we interpret the
lack of a
		   version identifier to mean, "this URL refers to the
default revision"?

		Addressing this problem is one of the reasons I support
Jim's original
		proposal of a "VPortal" to reference revisions, although I
renamed
		it a "Workspace", and generalized it to handle versioned
collections
		(see my earlier "Versioned Collections" message).

		In particular, in this proposal, a MOVE or COPY applied to
the URL of
		a versioned resource results in a move or copy of the entire
versioned
		resource.  The underlying CM engine must be allowed to cause
a MOVE to
		fail, if it does not support the movement of versioned
resources.
		Similarly, both a COPY and a MOVE of a versioned might fail
if the
		destination "repository" of the method is incompatible with
the "source"
		repository that contains the versioned resource.

		Cheers,
		Geoff
Received on Monday, 30 November 1998 14:19:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:48 GMT