Re: versioned collections: a proposal
Chris Kaler (ckaler@microsoft.com)
Mon, 30 Nov 1998 11:46:58 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757936@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
Date: Mon, 30 Nov 1998 11:46:58 -0800
Subject: RE: versioned collections: a proposal
I haven't read through all of this (I will), but here are some quick
comments.
I agree that versioned collections are difficult. 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.
I don't think that collections have references is viable. 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. 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.
Chris
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Monday, November 09, 1998 4:14 AM
To: ietf-dav-versioning@w3.org
Subject: versioned collections: a proposal
* Versioned Collection Challenges
As has been pointed out in several messages, versioned
collections
present a couple of challenging use cases.
First, when a versioned resource is "deleted" from a
versioned
resource collection, the resource itself cannot actually be
deleted,
since it still must be visible in the earlier revisions of
that
versioned resource collection.
Second, when a new revision is to be selected from a
versioned
resource that is the leaf of a nested set of versioned
collections,
the appropriate versions of the containing collections must
exist and
be selected in order for that new leaf revision to be
visible.
In order to relieve simple versioning systems from having to
address these problems, I propose that we only support
versioned
collections as part of DAV:configurations and not part of
DAV:basicversioning. I also propose that the following
constructs
replace the corresponding constructs of section 5
("Configurations")
of draft-webdav-versioning-00.
* Repositories, Configurations, and Workspaces
To support versioned collections, I propose that the members
of a
revision of a versioned collection should be *references* to
other
*versioned resources* (not the versioned resource itself,
nor a
references to particular revisions). I further propose that
the
versioned resources referenced by collection revisions be
members of a
special non-versioned collection called a "repository".
Having collection revision members be references solves the
first
versioned collection problem (what is deleted is a reference
to the
versioned resource, not the versioned resource itself). To
solve the
second problem, I propose that we introduce a special XML
element
called a "configuration" to provide an extensible mechanism
for
defining version selection, and that we introduce the
concept of a
"workspace" resource as a mechanism for combining a
versioned
collection with a configuration, to "instantiate" the
collection
revisions (i.e. to produce collections whose members are the
revisions selected by the configuration from the versioned
resources that are the members of the collection revision).
In addition, just as repositories provide the collections
that
contain the versioned resources, workspaces will provide the
collections
that contain the working resources.
* Definitions
"Repository" - a non-versioned collection resource that
contains
versioned resources.
"Configuration" - an XML element that defines a version
selection
rule, i.e. a configuration can be used to select a specific
revision
of a given versioned resource.
"Workspace" - a non-versioned resource that contains
"instances" (or
is an "instance") of a revision of a versioned resource. An
instance
of a non-collection revision is either a reference to the
revision, or
is a working resource created by checking out the revision.
An
instance of a collection revision is a non-versioned
collection, each
of whose members is an instance of a revision of a member of
the
collection revision being instantiated.
(Note: a workspace can be seen as a generalization of the
"VPortal"
concept from Jim Whitehead's original Versioning protocol
proposal.
* Predefined Configuration Elements
Although a configuration is intended to be an extensible
concept,
a few common configuration elements will be pre-defined.
- LABEL-CONFIG element: the XML element specifies the name
of a label.
This will select the revision of a versioned resource with
that label.
- BRANCH-CONFIG element: the XML element specifies the name
of a branch.
This will select the latest revision of that versioned
resource on that
branch.
- DATED-BRANCH-CONFIG element: the XML element specifies
both
the name of a branch and a date. This will select the
latest revision
of that versioned resource on that branch on or before the
specified date.
* Version Selection Conflicts
If multiple configuration elements are specified in a
configuration,
a "conflict" can result if the configuration elements select
incompatible
revisions (e.g. two revisions on different branches of the
versioned
resource).
* Workspace Properties
The WORKSPACE-ROOT property of a workspace specifies the
versioned
resource of which the workspace is an instance. If the
WORKSPACE-ROOT
is a collection, then a revision of each of the members of
that
collection is instantiated in that workspace as well.
The WORKSPACE-CONFIGURATION property of a workspace
specifies the
rules for selecting which revisions are instantiated in the
workspace.
The WORKSPACE-CONFLICTS property contains an XML element
describing
all conflicts produced when the WORKSPACE-CONFIGURATION is
instantiated on the WORKSPACE-ROOT.
* Working Resources Properties
When a working resource is created following a checkout, the
working
resource will be "from a specific revision", "on a specific
branch",
and "in a specific workspace". This information is stored
in the
WR-REVISION, WR-BRANCH, and WR-WORKSPACE properties of the
working
resource.
* An Example
For this example, I will assume that the repository is
implemented as
just a directory containing a set of RCS files, and a
workspace is
implemented as a directory tree containing copies of the
appropriate
revisions. For a more sophisticated configuration
management system,
one or more databases would normally be used to supplement
(or
replace) the set of files containing the revisions of a
versioned
resource, and various file caches used to share revisions
between
multiple workspaces.
I will further assume that a versioned collection will be
represented
as a special RCS file with a ".dir,v" extension, where each
revision
of a versioned collection consists of a list of member id's
with the
URI of the appropriate versioned resource.
The example repository would have then have a URI such as:
http://www.rational.com/web-dav/repo/test/
and would have members such as:
http://www.rational.com/web-dav/repo/test/src.dir,v
http://www.rational.com/web-dav/repo/test/inc.dir,v
http://www.rational.com/web-dav/repo/test/hello.c,v
http://www.rational.com/web-dav/repo/test/msg.h,v
http://www.rational.com/web-dav/repo/test/print.c,v
Using my earlier proposal that versioned resources be
collections,
the revisions of "hello.c,v" would have the URI's such as:
http://www.rational.com/web-dav/repo/test/hello.c,v/r1.0
http://www.rational.com/web-dav/repo/test/hello.c,v/r1.1
http://www.rational.com/web-dav/repo/test/hello.c,v/r1.1.1.0
http://www.rational.com/web-dav/repo/test/hello.c,v/r2.1
http://www.rational.com/web-dav/repo/test/hello.c,v/r2.1.1.0
The contents of:
http://www.rational.com/web-dav/repo/test/src.dir,v/r2.1
would then be lines of text such as:
hello.c
<http://www.rational.com/web-dav/repo/test/hello.c,v>
print.c
<http://www.rational.com/web-dav/repo/test/print.c,v>
inc
<http://www.rational.com/web-dav/repo/test/inc.dir,v>
Then there could be a few workspaces with URI's:
http://www.rational.com/home/gclemm/ws/dev/
http://www.rational.com/home/gclemm/ws/integ/
http://www.intersolv.com/home/sarge/ws/dev/
where the properties of:
http://www.rational.com/home/gclemm/ws/dev/
could be:
<D:prop>
<D:workspace-root>
http://www.rational.com/web-dav/repo/test/src.dir,v
</D:workspace-root>
<D:workspace-configuration>
<D:label-config> stable </D:label-config>
</D:workspace-configuration> </D:prop>
Assume that "print.c" is checked-out in "gclemm/ws/dev".
Also assume that the following revisions:
http://www.rational.com/web-dav/repo/test/src.dir,v/r2.1
http://www.rational.com/web-dav/repo/test/inc.dir,v/r1.0
http://www.rational.com/web-dav/repo/test/hello.c,v/r1.5
http://www.rational.com/web-dav/repo/test/print.c,v/r1.2
http://www.rational.com/web-dav/repo/test/msg.h,v/r1.3
each have the property:
<D:prop>
<D:label> stable </D:label>
</D:prop>
Then a recursive listing of the workspace "gclemm/ws/dev"
would be:
http://www.rational.com/home/gclemm/ws/dev/
http://www.rational.com/home/gclemm/ws/dev/src/
http://www.rational.com/home/gclemm/ws/dev/src/hello.c
http://www.rational.com/home/gclemm/ws/dev/src/print.c
http://www.rational.com/home/gclemm/ws/dev/inc/
http://www.rational.com/home/gclemm/ws/dev/inc/msg.h
where "hello.c" is a reference to:
http://www.rational.com/web-dav/repo/test/hello.c,v/r1.5
where "msg.h" is a reference to:
http://www.rational.com/web-dav/repo/test/msg.h,v/r1.3
and where print.c is a working resource.