Re: Notes from 5/3/99 Versioning TeleConf

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 4 May 1999 21:49:51 -0400 

Date: Tue, 4 May 1999 21:49:51 -0400
Message-Id: <9905050149.AA07467@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: Edgar.Schwarz@de.bosch.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <Pine.GHP.4.05.9905041228400.3928-100000@hpmx15.bk.bosch.de>
Subject: Re: Notes from 5/3/99 Versioning TeleConf


   From: Edgar Schwarz <Edgar.Schwarz@de.bosch.com>

   On Mon, 3 May 1999, Geoffrey M. Clemm wrote:

   > Jim further suggested that the configuration revision actually *be* this
   > collection.

   That's something im doing in practice for SCM. A configuration for my
   purposes is just a file containing a list of files with a revision id.
   Or do I miss something.

This is one possible implementation, but it is not one that scales up
particularly well (e.g. consider changing 3 resources in a 10,000
resource web site, and then creating a new snapshot of that web site).
It is important that the protocol be suitable for a wide range of
implementations.

   > I'm a little more hesitant about that, since I'm concerned that there
   > will be other "collections" that we will want to associate with a
   > configuration revision.  I don't have anything particular in mind yet,
   > but I'm still concerned that something will turn up.

   But it would be a elegant and simple solution.

Already two such "collections" have shown up ... the collection containing
the versioned resources that define the "scope" of the snapshot, and a
collection created at checkin time containing the revisions that the new
snapshot selects (the latter corresponds to the list of files with revision
id's that you describe above).  This just means that a snapshot needs to
contain several "sub-collection" members.

   > We then discussed the "create a configuration revision without using
   > a workspace" issue.  Chris indicated that the "configuration workspace"
   > described in the agenda makes sense, but is concerned that there are
   > complexities associated with introducing another flavor of workspace,
   > since we already have "checkout-token workspaces" and "version-selection
   > workspaces".

   I think that there should be configurations without any need for a
   workspace, activity or other thing.
   As I already wrote before I think that configurations are necessary
   already in level 1 versioning to make level 1 useful. So let's make them
   as simple as possible.

Making them as simple as possible is certainly one goal.  Another goal
is interoperability between different servers.  A common implementation
of a snapshot will be one that provides a compact, efficient persistent
representation, and another that provides rapid revision selection.
If the client "puts the snapshot in a workspace", the server can interpret
this as a hint that the compact persistent representation should be
converted to the rapid revision selection form.  This has minimal
impact on a client, but major impact on the scalability of the protocol.

   > Jim Amsden suggested that we just allow a list of revisions to be
   > specified when creating the configuration revision.  My concern with
   > this approach is that the server should confirm that the list of
   > revisions is a "legal" configuration (e.g. that it specifies at most
   > one revision of each versioned-resource, and that it selects a
   > revision of each internal member of a collection revision),

   I have to think about that. Are these restrictions really necessary ?

One revision per versioned-resource is necessary if it is to provide
an unambiguous revision selection.  Selecting all the members of a
collection revision is necessary in order to avoid a "no revision selected"
error when the snapshot is used to select revisions of that collection.

Cheers,
Geoff