From: email@example.com To: firstname.lastname@example.org, email@example.com cc: firstname.lastname@example.org Message-ID: <85256700.005FB1AB.email@example.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?