FW: configurations and snapshots
Jim Whitehead (ejw@ics.uci.edu)
Fri, 2 Apr 1999 11:25:22 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Fri, 2 Apr 1999 11:25:22 -0800
Message-ID: <000e01be7d3e$8d7d5c40$d115c380@ics.uci.edu>
Subject: FW: configurations and snapshots
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Thursday, April 01, 1999 11:14 AM
To: Jeff McAffer OTT
Cc: jamsden@us.ibm.com; gclemm@atria.com; ejw@ics.uci.edu;
dgd@cs.bu.edu; Cragun.Bruce@gw.novell.com;
sridhar.iyengar@mv.unisys.com; ckaler@microsoft.com;
bradley_sergeant@intersolv.com; ABabich@filenet.com;
Jeff_McAffer@oti.com
Subject: RE: configurations and snapshots
Jeff_McAffer@oti.com (Jeff McAffer OTT) on 04/01/99 01:24:08 PM
To: gclemm@tantalum.atria.com (Geoffrey M. Clemm), Jim Amsden/Raleigh/IBM
cc: ejw@ics.uci.edu (ejw), dgd@cs.bu.edu (dgd),
Cragun.Bruce@gw.novell.com (Cragun.Bruce), ckaler@microsoft.com
(ckaler), bradley_sergeant@intersolv.com (bradley_sergeant)
Subject: RE: configurations and snapshots
<jm>
- Can I spec an RSR to use the "latest" revision of a configuration? If
no, why not?
<jra>
Yes, use the floating, DAV defined label "latest".
</jra>
- If yes, would that be called "putting a snapshot into the RSR?" If so,
"snapshot" does not refer to a specific configuration revision and the
terminology is inconsistent. We may as well say "put a configuration in
the RSR" and have it be understood that you can put a particular revision
there or just leave it be the latest.
<jra>
Specific revisions apply to configurations not workspaces. If you put the
"latest" revision of a resource in a configuration, either through a
snapshot or by explicitly adding the revision with the "latest" label,
you'll get a particular revision in that configuration and it will never
change. The member of the configuration is identified by its URI, not its
URL and label. This is because you can move a label yourself from one
revison to another, and this can't change a configuration either. It could
change what a workspace selects though.
</jra>
A fundamental question that keeps coming back to me is "how do we deep
version collections?". Has there been agreement on this? Here are some
assumptions. Please correct me where I am wrong ( as I am sure I am):
1) There is no effective way of deep versioning a collection without
using configurations.
<jra>
Yes there is, see below.
</jra>
2) Configurations capture the entire state of a workspace
<jra>
No. If you snapshot a workspace, then the created configuration contains
the immutable revisions selected by that workspace, not the rest of its
state. Otherwise, the configuration, like Envy/Smalltalk, contains only
what you put in it.
</jra>
3) Users do not always want to version all the resources on which they
are working
<jra>
Yes, and they don't necessarily want to version all configurations either,
or have a configuration always contain everything visible in their their
workspace. Configurations contents must be under the fine control of the
user in order to support effective reuse.
</jra>
<jra>
The thing you version about a collection is its member URLs. Recall that
WebDAV specifies that a collection contains URLs of resources, not
resources. These URLs are not to specific revisions, but are the user URLs
of the versioned resources. When accessing a revision of a resource, the
server traverses the collections in the URL path asking each one for its
member URLs. These URLs are then mapped to revisions using the workspace,
just like any other resource. If the path entry is a sub-collection, the
process continues until it reaches the last element in the pathname.
So each collection URL or URL fragment is evaluated in the context of the
workspace to determine which revision of the collection is selected, and
therefore what member URLs that collection contains. If the revision
contains the next element in the path, then the process continues.
Otherwise a resource not found error is returned.
</jra>
If these are all true then we are going to have a lot of workspaces.
People (tool builders) are going to end up creating workspaces for every
collection of resources on which they want to support versioning in an
independent way. Untenable from both perspectives.
If configurations are some resource to which I can add and remove
elements then I can build a config taht contains only those portions of
the workspace in which I am interested. Cool but this would be somewhat
laborious if I wanted to version a large subtree and I had to add each
node individually. How do people see this working in real life?
<jra>
See the versioning model. Adding a collection to a configuration
recursively adds each of its members to the configuration. The member
revision selected depends on how the collection was added: through a label,
selected by the workspace, in an activity, etc. Just apply the same
selection mechanism recursively to each of the members. This would probably
be a best effor operation too.
</jra>