Message-ID: <4FD6422BE942D111908D00805F3158DF0A757936@RED-MSG-52> From: Chris Kaler <email@example.com> To: "'Geoffrey M. Clemm'" <firstname.lastname@example.org>, 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:email@example.com] Sent: Monday, November 09, 1998 4:14 AM To: firstname.lastname@example.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/r188.8.131.52 http://www.rational.com/web-dav/repo/test/hello.c,v/r2.1 http://www.rational.com/web-dav/repo/test/hello.c,v/r184.108.40.206 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.