Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
Chris Kaler (ckaler@microsoft.com)
Mon, 25 Jan 1999 13:24:38 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757C02@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>
Cc: ietf-dav-versioning@w3.org
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
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