Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus

jamsden@us.ibm.com
Mon, 25 Jan 1999 22:12:30 -0500 

From: jamsden@us.ibm.com
To: Chris Kaler <ckaler@microsoft.com>
cc: ietf-dav-versioning@w3.org
Message-ID: <85256705.001287ED.00@d54mta03.raleigh.ibm.com>
Date: Mon, 25 Jan 1999 22:12:30 -0500
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus



Chris, I think we are saying similar things, just with slightly different
language. The reason for two lists is that there are two relationships,
is-derived-from, and was-derived-from having different semantics. The
ancestor/descendents for these two relationships may be different. It's not
enough to know that a revision has been mutated, we also need to know where
it came from. This is required for useful merge conflict lists. Otherwise
you can't know what needs to be merged, and when you're done. The
precdecessor/successor roles model the stronger is-derived-from
relationship.

For configurations/parallel development, I think we're even closer. Think
of a revision as a particular instance of a versioned resource. A
configuration is a particular instance of a select set of revisions. For
parallel development, we introduce the notion of activity which represents
a set of changes to revisions that are likely taken together. So an
activity is like a configuration, except it gives what you have changed or
are changing in the activity. A configuration is a persistent set of
revisions while an activity can change anytime. A revision can be checked
out in many activities if the server supports parallel development.

A workspace is a resource used to resolve resource URLs. A workspace
contains a version selection rule and a current activity. Access to a
versioned resource is always done in the context of some workspace.
Activities can be merged, and the differences between configurations can be
given as a list of activities, each activity containing a list of resources
that are different.






Chris Kaler <ckaler@microsoft.com> on 01/25/99 04:24:38 PM

To:   Jim Amsden/Raleigh/IBM
cc:   ietf-dav-versioning@w3.org
Subject:  RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus





Sorry for not replying sooner, got bit by the flu bug...

I'm a little worried about the combinatorics of what you proposed.

1. We talked about a list of pred/succ revisions
2. We realized that clients have more semantic information, so
   we needed a second list
3. Geoff pointed out that having a single merged list is valuable
4. We decided we needed a "primary" pred/succ in there are multiple
5. We need to differentiate these lists by mutable or non-mutable

I realize that (5) is not what everyone is saying exactly, but that
is the next logical step.

I guess what I don't understand is why this is such an issue.  The
question is, can I trust the pred/succ?  If there is a property that
indicates if a revision has been mutated :-), why isn't this enough?
Clients know that they can't trust the data.  Why do we need separate
lists?

Also, I still think there are two types of configurations: those for
reproducing exact "configurations" (sorry for the recursion), and those
for managing parallel development.  The first is what we usually call
a label.  The second is what I was calling a workspace.  A collection
of "threads" (to use the term from the last meeting) for multiple
resources.

This should make for an interesting conversation in Utah :-)

Cheers,
Chris