Mutable Revisions

jamsden@us.ibm.com
Sun, 24 Jan 1999 11:12:50 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256703.0059B08A.00@d54mta03.raleigh.ibm.com>
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.