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

Chris Kaler (
Mon, 25 Jan 1999 13:24:38 -0800

Message-ID: <4FD6422BE942D111908D00805F3158DF0A757C02@RED-MSG-52>
From: Chris Kaler <>
To: "''" <>
Date: Mon, 25 Jan 1999 13:24:38 -0800
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

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 :-)