Re: versioned collections: a proposal
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 1 Dec 1998 10:11:44 -0500
Date: Tue, 1 Dec 1998 10:11:44 -0500
Message-Id: <9812011511.AA12100@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ckaler@microsoft.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A757936@RED-MSG-52> (message
Subject: Re: versioned collections: a proposal
From: Chris Kaler <ckaler@microsoft.com>
I agree that versioned collections are difficult.
Just to be clear, I believe that you have to be careful when you are
designing versioned collection support because several obvious
approaches don't work, but I don't believe supporting/implementing
them is difficult/expensive if you get the design right.
For that reason I added
the properties to discover what level of collection versioning a resource
supported. I think it is reasonable to make this generally optional.
Certainly it should be optional whether or not a given collection is a
versioned resource (just as is the case for non-collections). I
strongly disagree that "versioned collections" should be an optional
part of WebDAV versioning support, since without them, there's no way
to have a reliable mechanism for accessing previous versions of a Web site.
I don't think that collections have references is viable.
That will come as a shock to the advanced collections team (:-).
First, the client
should have to do anything different if it is working on a versioned
collection that if it is working on a non-versioned collection. This is
hard, but not impossible using references.
How is this hard? The purpose of direct references is specifically to
make this possible/easy.
However, I think the namespace
shouldn't differ at all. That is, I should be able to take a Web site that
isn't versioned, and enable versioning on it without requiring the structure
of the Web site to be changed.
With all the versioning systems I know of, when you convert a resource
from being non-versioned to being versioned, a new object (the
"versioned resource") is created, either in some directory (e.g. an
RCS ",v" file) or in some repository. If you consider the addition of
a "repository" resource to the Web site (to hold the versioned
resources) to be a structure change, then I will argue both that this
is a very minor and a very necessary restructuring.
Note that the addition of the repository is the only change to the
user visible "structure". The tree that has been placed under version
control now is a "workspace", but the structure of the workspace is
identical to the structure of the tree before it was placed under
version control.
Cheers,
Geoff