From: firstname.lastname@example.org To: email@example.com Message-ID: <85256703.0059B08A.firstname.lastname@example.org> Date: Sun, 24 Jan 1999 11:12:50 -0500 Subject: Mutable Revisions Geoff, I think I have a way to "merge" our two ideas for managing mutability that gives up both what we want while keeping the protocol simple. The thing I like about your approach is the semantics of checkout for protecting resources is more formal than lock, and provides consistent semantics between DMS and CM style servers. On the other hand, my approach lets you mix mutable and immutable revisions on the same resource which seems reasonable. Take a look at the use case I added to the goals document for this. Here's the idea: 1. To make any change to a versioned resource, you must check it out first, even if the revision being checked out is mutable. This means that you can't PUT or PROPPATCH a mutable revision without checking it out first. This is different than my original proposal, and eliminates the need for freeze/thaw. Checkout/checkin play that role. 2. At checkout time, you can decide if you want to create a new revision, or update the existing revision. This option is only available on mutable revisions. Immutable revisions will always require a new revision. So this is the same as your checkout and checkoutNew (I would probably use a parameter and one method though). 3. At checkin time, you decide if you want your new revision (no matter how it was checked out) to be mutable or not. This comes from my proposal. If the ancestor is mutable, and you want to checkin immutable, then the predecessor relationship is set to the closest immutable ancestor if any. The was-derived-from relationship is still to the original ancestor, so the is-derived-from and was-derived-from relationships are to two different ancestors. I think this supports all the rules required for merging and CM, provides flexibility, preserves checkout semantics on revisons, and is very simple. 4. Servers are free to disallow checkout without creating a new version, and to checkin as a mutable revision. Servers that provide both DMS and CM semantics can choose the defaults on checkout (new or not), and checkin (mutable or not). This is the distinction between DMS and CM servers. DMS servers have the extra flexibility, but loose merge reports and configurations on mutable revisions. CM servers trade off the flexibility for the richer semantics for merge and configurations. Clients can either be DMS, CM, or even both if desired. What do you think? I haven't thought about the implementation implications, but it seems like this could be implemented any number of ways.