
Mon, 25 Jan 1999 22:12:30 -0500

To: Chris Kaler <>
Message-ID: <>
Date: Mon, 25 Jan 1999 22:12:30 -0500

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

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 <> on 01/25/99 04:24:38 PM

To:   Jim Amsden/Raleigh/IBM


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

is the next logical step.


for managing parallel development.  The first is what we usually call

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