versioned collections: a proposal

Geoffrey M. Clemm (
Mon, 9 Nov 1998 07:14:15 -0500

Date: Mon, 9 Nov 1998 07:14:15 -0500
Message-Id: <9811091214.AA01046@tantalum>
From: "Geoffrey M. Clemm" <>
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
- 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

* 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

* 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:

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

Using my earlier proposal that versioned resources be collections,
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:

  hello.c <,v>
  print.c <,v>
  inc     <,v>

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

where the properties of:

could be:

    <D:workspace-root>,v </D:workspace-root>
      <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.