Re: IETF Versioning Meetings

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 10 Mar 1999 00:56:00 -0500


Date: Wed, 10 Mar 1999 00:56:00 -0500
Message-Id: <9903100556.AA12368@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sv@crystaliz.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <008201be6673$f86d56e0$d0acddcf@yokohama.crystaliz.com>
Subject: Re: IETF Versioning Meetings

   From: "Sankar Virdhagriswaran" <sv@crystaliz.com>

   >A revision of a collection is modified by adding or removing members.
   >Changing the contents of a member of a revision of a versioned collection
   >does not imply a change to the parent collection.

   I may be confused about what you are trying to say, however, I wonder if
   this assumption is too strong for dependency analysis. If a programmer is
   writing code (file A) that is dependent on the specification of the program
   (file B) and if both of these are being kept together as a semantically
   meaningful collection, then modifying file B or A does impact the semantic
   consistency of the collection. Does this make sense?

There are two "levels" of collection versioning.  The first "base level"
is the one Jim describes, i.e. a collection is changed (and therefore
requires to be checked-out) only if you are adding or deleting an
immediate (level 1) member of the collection.

If you care about the revision selection choices in a tree rooted at a
particular collection, you would capture the revision state of all
members of that tree in a "configuration".  If any revision selection
changed for any member, this would be reflected in a new
configuration.  If you version configurations (which I believe you
should), then you use revisions of a configuration to capture the
evolution of that tree.

   >Parallel Development with Activities
   >
   >Resources are checked out in the context of an activity. An activity
   >abstracts a set of related changes a user is making to versioned resources.
   >Each activity represents a parallel thread of development. Servers that
   >don't support parallel development effectively only support one, default
   >activity.

   Are nesting of activities allowed? If not this model is too restrictive for
   web site development and deployment. Furthermore, if nested activities are
   allowed then are 'continuation' of activities after intermeidate submissions
   are made allowed?

I'm also believe support for "parent" or "nested" activities is essential.
Some other members of the design team or less decided, so feedback pro/con
from the mailing list is encouraged!

   There are two fundamental notions here. Change and compound change. It
   sounds like your description covers the 'change' concept, it does not cover
   the 'compound change'.

This is a good summary of the need for nested activities.

   >A workspace contains a current activity and a revision selection rule.

   I don't understand the semantics of 'contained'. The way I think about it
   each activity is associated with a workspace and each workspace has
   selection rules. Am I missing something.

I think you've got it.  The word "contains" should probaby be changed,
since it sounds like collection membership, which is not the case.
Note that only (at most) one activity will be the current activity of
a workspace at any moment (that's the one that new checkout's will go
into), so at a single moment most activities will not be the current
activity of a workspace (although if they have any revisions, they
must have been the current activity of some workspace at some point).

   >Revisions are selected using the following rules in order: 1) if there is a
   >checked out revision, then it is selected. else 2) if there is a revision
   >that is checked in under the current activity, then the latest revision in
   >this activity is selected, else 3) the workspace revision selection rule is
   >applied to select the revision. If there is no matching revision, then a
   >resource not found status is returned. This rule is applied to collections
   >to select the revision that determines their member versioned resources,
   >and to other resource to determine the revision containing their contents.

   Could you provide some rationale for why the ordering? I am confused. I
   would think that the simplest case (and hence the default case) would be to
   allow users to checkout named (and not labeled) revisions in the context of
   a workspace and there is no 'view rule' processing required. Don't you
   thinking processing of view rules should be followed after this. Maybe that
   is what you are saying, but just wanted to make sure.

We have agreed to get rid of rule (2), so that just leaves:
"checked-out else whatever the revision-selection-rule picks".
Does this correspond better to your intuition?  (It's what I'd
like for us to say, anyway).  Some people are going even further
and saying that "a workspace doesn't even have to select the working
resources checked out into it, that's just one of the possible
revision-selection rules".  That makes less sense to me than
requiring that at *least* a workspace must (always) select the
working resources checked-out into it.

   >Versioned Collections
   >
   >A collection contains a set of members. For versioned collections, the
   >members are versioned resources, not particular revisions. To add or remove

   I assume versioned collections can contain other collections. Is this
   assumption correct?

Yes.

   >the current workspace specify revisions that are on different
   >lines-of-descent, and a potential merge conflict exists and is included in
   >the merge conflict report.

   How are dependency conflicts captured in this model? Are they excluded in
   the current thinking?

I believe the answer is "yes", but if you have a dependency conflict model
in mind, please send it in for consideration.  The main reason that we have
not dealt with dependency conflicts is that there seems to be very little
commonality in servers today that we could capture in a protocol.

Great comments, and thanks for the careful analysis!!

Cheers,
Geoff