FW: snapshots
Jim Whitehead (ejw@ics.uci.edu)
Fri, 2 Apr 1999 10:14:48 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Fri, 2 Apr 1999 10:14:48 -0800
Message-ID: <000201be7d34$b1a4ede0$d115c380@ics.uci.edu>
Subject: FW: snapshots
Here's a more recent thread that started among the design team which I'm
also forwarding to the list.
- Jim
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Wednesday, March 31, 1999 8:41 PM
To: ckaler@exchange.microsoft.com
Cc: jamsden@us.ibm.com; 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.
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.
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.
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.
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.
Cheers,
Geoff