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.