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

jamsden@us.ibm.com
Thu, 21 Jan 1999 12:21:40 -0500 

From: jamsden@us.ibm.com
To: gclemm@tantalum.atria.com, yarong@microsoft.com
cc: ietf-dav-versioning@w3.org
Message-ID: <85256700.005FB1AB.00@d54mta03.raleigh.ibm.com>
Date: Thu, 21 Jan 1999 12:21:40 -0500
Subject: Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus



At the Orlando IETF meeting we (Geoff, Yaron, and I) came up with an
agreement on the semantics of mutable/immutable revisions that it seems we
are backing away from now. As I recall, we came up with some pretty simple
semantics that provided what everyone wanted without requiring different
server options. Here's what I remember was the conclusion of the "pool"
discussion:

1. Mutability of a revision is a property of the revision, not the server.
It is up to the author to determine on a revision-by-revision basis whether
a revision is mutable or not.

For example, a revision of a static document might be considered mutable if
it has no legal issues as changing a revision would have no significant
consequences. On the other hand, a servlet accessing a database query
returning sensitive business information as part of a complex e-business
application might need to be immutable so different versions of the
application can be deployed. It is also possible that both resources
participate in the same application.

2. Revisions can be related in two different ways: successor/predecessor,
and derived from. These are different relationships having different
semantics.

These relationships reflect the different versioning semantics of document
management systems and typical CM systems. There is really no problem
having two relationships. We just have to define the semantics and the
methods to create them. These follow:

3. A mutable revision cannot participate in a successor/predecessor
relationship because the semantics of such a relationship are not
maintained.

This allows a server to know and rely on the meaning of
successor/predecessor relationships which enables support for merging and
configuration semantics.

4. A versioned resource has two revision histories, the
successor/predecessor history, and the derived from history. The actual
semantics of derived from relationship are not specified by WebDAV as they
are unpredictable, WebDAV only maintains the relationship. Both histories
are available through the same query.

5. A working revision of a versioned resource revision (mutable or not) is
created by checking out the resource.

There is no change in checkout semantics for mutable or immutable
revisions. If the revision is already checked out, then the checkout will
fail. The author must set the current activity in his workspace to a new
activity and checkout the revision in the new, parallel activity.
Mutability is not derived from the checked out resource, nor is it
determined at checkout time (you don't have a revision yet).

6. An author determines whether a revision is mutable or not when the
revision is checked in. This establishes the full relationship with the
revision that was checked out. If it is checked in as an immutable
revision, then the relationship is successor/predecessor. If it is checked
is as mutable, then the relationship is derived from.

This lets the author decide on a revision-by-revision, resource-by-resource
basis the mutability of a revision. This is not specified as a server
option. Client applications can exploit either or both semantics on any
server. That is, the server provides both mechanisms, and the client picks
the policy it wants. As Yaron pointed out, this approach won't scale to too
many different semantic variants, so we should pick them carefully. But in
general, the server is about mechanism, and the client is about exploiting
mechanism to provide specific policies.

7. If a working version was checked out from a mutable revision, and
checked back in as immutable, then the predecessor/successor relationship
is established with the closest immutable predecessor up the line of
descent.

This is required to ensure the semantics of successor/predecessor can be
maintained.

8. Mutable revisions cannot be members of a configuration.

This is required to support the usual expected semantics of configurations:
reproducibility.

9. A mutable revision  cannot be the source of a merge.

This is required to support deterministic merging and reliable merge
conflict lists. Note the last two indicate that parallel development and
configuration management are not well supported for mutable revisions, and
would not likely be available to DMS clients. It is assumed that DMS
clients are not as interested in these facilities as mutable revisions
would cause unpredictable and unexpected results. Note however that if they
become interested, all they need to do is change a header on checkin to
make the revision immutable, and they get all the parallel development and
configuration management semantics from then on, on the same resource and
on the same server.

10. A mutable revision can be changed with a simple PUT or PROPPATCH. It
does not need to be checked out in order to change its contents or
properties. The is no record of these changes maintained by the server
other than the last modified DAV property.

We could include "thaw"/"freeze" operations that work only on mutable
revisions to make changing them harder, thereby highlighting the
consequences of such an operation, but I don't believe this is worth the
bother.

11. An immutable revision can never be made mutable.

This again ensures the integrity of successor/predecessor relationships and
the semantics that depend on them. If an author wants a mutable version, he
can checkout the immutable revision, and check it back is as mutable in
order to create a new, mutable revision. If the resource is already checked
out, then this would require a new activity.

12. Workspace version selection rules can include mutable and immutable
revisions.

So there is no change in how revisions are accessed. However, a mutable
revision cannot be in a configuration, so this limits the version selection
rules that can be used to specify mutable revisions.

13. Activities can contain mutable revisions, but these activities cannot
be the source of a merge.

We may want to modify the semantics of the conflict list to include
line-of-descent conflicts of immutable revisions, and an indication of
potential, undetermined conflicts that could arise at any time due to
changes in mutable revisions. Then at least the server could tell the
author about the potential for lost updates even though it can't ever
indicate the conflict is resolved as it can for line-of descent conflicts
when the merge is completed.

So I think there are only a few protocol consequences to these rules.

1. checkin needs a header to indicate if the new revision is mutable or
not.

2. The protocol for accessing the history needs to indicate is the
predecessor/successor, derived from, or both histories are desired.

3. The other methods must support the semantics above, but there shouldn't
be any protocol changes required.

This needs to be more fully thought out, and tested against the as yet
unknown or unspecified scenarios. But I think this is what we agreed to at
Orlando, seems pretty simple, does what I think the DMS people want,
answers the interoperability question, would be relatively easy to
implement, maintains the semantics required to support deterministic
parallel development and configurations, eliminates server options, and
keeps the protocol simple.

Am I missing something? Is this what we agreed to? Does it do what we want?