Re: snapshots
Jim Whitehead (ejw@ics.uci.edu)
Fri, 2 Apr 1999 11:03:41 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Fri, 2 Apr 1999 11:03:41 -0800
Message-ID: <000901be7d3b$85a0c140$d115c380@ics.uci.edu>
Subject: Re: snapshots
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Thursday, April 01, 1999 8:23 AM
To: Geoffrey M. Clemm
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: snapshots
See <jra> tags below.
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 03/31/99 11:41:22 PM
To: ckaler@Exchange.Microsoft.com
cc: Jim Amsden/Raleigh/IBM, ejw@ics.uci.edu, dgd@cs.bu.edu,
Cragun.Bruce@gw.novell.com, bradley_sergeant@intersolv.com,
Jeff_McAffer@oti.com
Subject: Re: snapshots
I agree that a configuration should be a versioned resource, and that
a configuration revision is a key element in a revision selection
rule. I agree with Chris that it is worth having a simple term for
"configuration revision" (if nothing else, those 8 syllables are quite
a mouthful :-).
I continue to strongly resist defining a snapshot as being just a
special kind of collection that you can check out, freely add and
delete members, and then check-in. This resistance is completely
based on pragmatic implementation concerns, not on any logical
problem.
<jra>
A snapshot isn't a collection, its a configuration created by taking a
snapshot of a workspace. This might be a collection, and I suggest we make
configuration a subclass of collection in the model as it has lots of
collection semantics.
However I think a configuration should ALSO be able to be created just like
any other resource: create an empty one, add revisions to it, check it in
if desired, etc. If a configuration is a kind of collection whose members
must be references to revisions, then it would seem that updating a
configuration is trivial.
</jra>
In particular, some key snapshots will commonly be very large, i.e. a
snapshot of the entire web site. There are several important use
cases where these snapshots will be taken frequently. For example, I
update my web site several times a day, and I want to snapshot the web
site immediately following each update, so that I can quickly roll
back to any such state.
<jra>
Conversely there will be a number of small configurations that represent
reusable collections of components that make up specific libraries or web
applications. Users should have the freedom to create configurations either
way depending on their needs.
</jra>
Now as a branch-based or activity-based CM provider, I have a very
convenient mechanism for quickly creating a snapshot: I can just
supplement the current RSR with a time-constraint, i.e. "the latest
revision on branch-xxx before 3am on June 3". I can create lots of
these snapshots very fast and very cheaply. But I *cannot*
efficiently implement an arbitrary "put this revision in" or "take
this revision out" operation, only a "snapshot the current state of
the workspace" operation.
<jra>
How efficient does creating an empty configuration and adding revisions to
it have to be? This is not something I think users will be doing on a
minute-by-minute basis. Its more like something they do when a merge was
done and its time to create a baseline for testing, distribution,
archiving, etc. This is often done on a daily basis by many organizations.
The actual operations should be no different than creating a collection and
adding members. In fact, that's probably a fine implementation.
</jra>
Given the power and flexibility of revision selection rules,
I don't see that the client is at all constrained by requiring
that they snapshot the state of the workspace instead of directly
manipulating the snapshot. In particular, you can use a label
revision selection rule, and move labels around if you want to
select an arbitrary set of revisions.
<jra>
Editing a revision selection rule and doing a snapshot is not a convenient
or flexible way to create configurations. It is only one way, one that
assumes everything visible in the workspace needs to be in the
configuration.
In my experience, this is generally not the case. Most work is done in a
larger context of reuse libraries, reference materials, experimentation,
incomplete work, etc. The workspace provides a view for all of these
resources in the context of developing a web site, application, or
document. When the work reaches a stable state, it is useful to select from
this wider context the resources that make up the deliverable the user or
users were trying to create. This is often very simple when updating a
revision of a configuration that just needs to change a few revisions.
The primary motivation for flexibility in creating configurations is to
support effective reuse of resources. The usage model is you look around at
all the things that are available (in your workspace view), and pick the
ones that meet your needs. Then some modifications are done to update
reusable resources to meet particular requirements (the deltas between what
a resource does and what a reuser of that resource needs it to do). One can
use a configuration as a grab-bag to put the revisions of the things they
need to make up their application.
</jra>
So I will need a compelling set of use cases that can't be easily
handled by existing protocol functionality before I am willing to
accept an addition to the protocol that requires me to support
something I cannot efficiently implement.
<jra>
See the Envy repository manager for Smalltalk. Configurations were one of
its better features.
</jra>
Cheers,
Geoff