FW: configurations and snapshots

Jim Whitehead (ejw@ics.uci.edu)
Fri, 2 Apr 1999 11:19:47 -0800 

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Fri, 2 Apr 1999 11:19:47 -0800
Message-ID: <000c01be7d3d$c56d3c20$d115c380@ics.uci.edu>
Subject: FW: configurations and snapshots



-----Original Message-----
From: Jeff McAffer OTT [mailto:Jeff_McAffer@oti.com]
Sent: Thursday, April 01, 1999 10:24 AM
To: Geoffrey M. Clemm; jamsden
Cc: ejw; dgd; Cragun.Bruce; ckaler; 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?
 - 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.

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.
2) Configurations capture the entire state of a workspace
3) Users do not always want to version all the resources on which they
are working

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?

Tell me to buzz off if these are rehashs of established knowledge (but
point me to where it is defined).
</jm>

> Just to make sure we separate semantics from terminology:
>
> There is an immutable object that captures a set of revisions, and is
> suitable for placing in a revision selection rule.  This is the most
> important object, and needs a name of its own.
>
> There are frequently a series of these immutable objects that are
> created, that are connected by a logical predessor/successor relation.
> In addition, there are cases where several such immutable objects are
> "merged" into a single new immutable object.  This means that this
> series of immutable objects looks very much like a special kind of
> versioned resource.



> Originally, we were using the term "configuration" for the
> first object,
> and had no name for the second object, other than "a
> versioned resource
> whose revisions are configurations".
>
> We (or at least, some of us :-) then switched to calling the *second*
> object a configuration, and the first object a "configuration
> revision".
> This gave us a usable name for both objects.  But the most important
> object now had a two-word, eight-syllable name, so we decided to give
> it a new name, "snapshot".  So now we can say "a snapshot is a
> configuration revision".
>
> So my conclusion from all this is that we need good names for each of
> these two objects, but I'm not attached to either one of the current
> names.
>
> Then a protocol question is:
> - Do you create a new snapshot with a "MKSNAPSHOT" method, or
> a pair of
> CHECKOUT/CHECKIN methods on an existing snapshot.
>
> And some *semantic* questions are:
> - Can you create a snapshot that is not part of a configuration?
> (if so, you must have MKSNAPSHOT)
> - Can you modify a checked-out snapshot, or can you only check it in?
> (only relevant if you use CHECKOUT/CHECKIN to create new snapshots)
>
> Cheers,
> Geoff
>