Re: versioned collections: a proposal

Chris Kaler (
Mon, 30 Nov 1998 11:46:58 -0800

Message-ID: <4FD6422BE942D111908D00805F3158DF0A757936@RED-MSG-52>
From: Chris Kaler <>
To: "'Geoffrey M. Clemm'" <>,
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

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.


		-----Original Message-----
		From:	Geoffrey M. Clemm []
		Sent:	Monday, November 09, 1998 4:14 AM
		Subject:	versioned collections: a proposal

		* Versioned Collection Challenges

		As has been pointed out in several messages, versioned
		present a couple of challenging use cases.

		First, when a versioned resource is "deleted" from a
		resource collection, the resource itself cannot actually be
		since it still must be visible in the earlier revisions of
		versioned resource collection.

		Second, when a new revision is to be selected from a
		resource that is the leaf of a nested set of versioned
		the appropriate versions of the containing collections must
exist and
		be selected in order for that new leaf revision to be

		In order to relieve simple versioning systems from having to
		address these problems, I propose that we only support
		collections as part of DAV:configurations and not part of
		DAV:basicversioning.  I also propose that the following
		replace the corresponding constructs of section 5
		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
		*versioned resources* (not the versioned resource itself,
nor a
		references to particular revisions).  I further propose that
		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
		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
		called a "configuration" to provide an extensible mechanism
		defining version selection, and that we introduce the
concept of a
		"workspace" resource as a mechanism for combining a
		collection with a configuration, to "instantiate" the
		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
		contain the versioned resources, workspaces will provide the
		that contain the working resources.

		* Definitions

		"Repository" - a non-versioned collection resource that
		versioned resources.

		"Configuration" - an XML element that defines a version
		rule, i.e. a configuration can be used to select a specific
		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
		of a non-collection revision is either a reference to the
revision, or
		is a working resource created by checking out the revision.
		instance of a collection revision is a non-versioned
collection, each
		of whose members is an instance of a revision of a member of
		collection revision being instantiated.

		(Note: a workspace can be seen as a generalization of the
		concept from Jim Whitehead's original Versioning protocol

		* Predefined Configuration Elements

		Although a configuration is intended to be an extensible
		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
		- DATED-BRANCH-CONFIG element: the XML element specifies
		  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
		a "conflict" can result if the configuration elements select
		revisions (e.g. two revisions on different branches of the

		* Workspace Properties

		The WORKSPACE-ROOT property of a workspace specifies the
		resource of which the workspace is an instance.  If the
		is a collection, then a revision of each of the members of
		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

		The WORKSPACE-CONFLICTS property contains an XML element
		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
		resource will be "from a specific revision", "on a specific
		and "in a specific workspace".  This information is stored
in the
		WR-REVISION, WR-BRANCH, and WR-WORKSPACE properties of the

		* 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
		revisions.  For a more sophisticated configuration
management system,
		one or more databases would normally be used to supplement
		replace) the set of files containing the revisions of a
		resource, and various file caches used to share revisions
		multiple workspaces.

		I will further assume that a versioned collection will be
		as a special RCS file with a ".dir,v" extension, where each
		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:

		and would have members such as:,v,v,v,v,v

		Using my earlier proposal that versioned resources be
		the revisions of "hello.c,v" would have the URI's such as:,v/r1.0,v/r1.1,v/r1.1.1.0,v/r2.1,v/r2.1.1.0

		The contents of:,v/r2.1

		would then be lines of text such as:


		Then there could be a few workspaces with URI's:

		where the properties of:

		could be:

		      <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:,v/r2.1,v/r1.0,v/r1.5,v/r1.2,v/r1.3

		each have the property:

		    <D:label> stable </D:label>

		Then a recursive listing of the workspace "gclemm/ws/dev"
would be:

		where "hello.c" is a reference to:,v/r1.5

		where "msg.h" is a reference to:,v/r1.3

		and where print.c is a working resource.