Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
Chris Kaler (ckaler@microsoft.com)
Thu, 21 Jan 1999 10:41:26 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757BE0@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'jamsden@us.ibm.com'" <jamsden@us.ibm.com>, gclemm@tantalum.atria.com,
Cc: ietf-dav-versioning@w3.org
Date: Thu, 21 Jan 1999 10:41:26 -0800
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
Some comments intermixed below...
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Thursday, January 21, 1999 9:22 AM
To: gclemm@tantalum.atria.com; Yaron Goland
Cc: ietf-dav-versioning@w3.org
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.
[CK] I think it is perfectly reasonable for a server to not support
mutable revisions. In Portland we discussed this and said that
FREEZE/THAW were optional and a server could fail all requests.
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.
[CK] I don't agree with that. I think the predecessor/successor
relationship
is still valid, you just can't make immutable guarantees. This is
bad for source control, but can be fine for some DMS systems.
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.
[CK] Agreed. Geoff wanted the ability to get a combined list and I
think that is fine as well.
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).
[CK] I guess I don't get what it means to "checkout" a mutable revision
that isn't the tip. That would imply a branch to me. Why wouldn't
I THAW it, GET it, PUT it, and FREEZE it? Although technically I
don't have a problem with THAW it, check it out, check it in, and
FREEZE it, it just seems weird because the checkout is creating a
mutable version which the "THAW" already did.
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.
[CK] I guess I don't see mutability as a checkin attribute. I think this
is an attribute of the revision. I think that it is fine to require
this to be an overt action by the user which the server can prevent.
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.
[CK] Except that a server MUST retain the right to not allow mutable
versions.
This is acceptable for a source control system, for example.
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.
[CK] Since I don't see the checkin changing the immutability, this seems
odd to me. I think we are getting the revision graph manipulation
involved where it doesn't belong. The scenario is simple. Version
3 of the document has a typo and I just want to fix it -- and I declare
that it is OK. The pred/succ relation doesn't change (2 is before 3
and
4 is after 3). The client can detect that revision 3 was THAWed and
see that the modified time is later than 4 and that's OK. If you
accept
THAW, then the pred/succ is a logical relationship and not guaranteed
to
be a physical one.
8. Mutable revisions cannot be members of a configuration.
This is required to support the usual expected semantics of configurations:
reproducibility.
[CK] I think this is too strong. A way to use a configuration is for
reproducibility, but I don't think that is the only value of a
configuration. I could also use it as a way to organize my work.
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.
[CK] I don't think we should have the server involved in merge. This is
a client operation that is reflected in the client-maintained
derivation
fields.
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.
[CK] Agreed -- although this seems to conflict the statements above.
Maybe I just missed something?
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.
[CK] I do. I think the gesture is important.
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.
[CK] I think this makes sense for source control systems, but not for DMS
systems. I think the FREEZE/THAW we agreed to in Portland is fine
and the properties can be used to detect if a revision has been
mutable.
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.
[CK] I assume this is through standard property selection semantics.
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.
[CK] It's not clear to me that a sweeping exclusion is always the right
thing to do.
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.
[CK] As stated, I disagree with this. This feels more like a resource
property that a method "side effect".
2. The protocol for accessing the history needs to indicate is the
predecessor/successor, derived from, or both histories are desired.
[CK] Agreed.
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?
[CK] I look forward to the Utah meeting to discuss this. I thought the
conversations in Portland were good, so I look forward to hearing
the discussion from Orlando. I'm still inclined to stick with
FREEZE/THAW, but hey, I like LOCK to check out :-)