Re: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
jamsden@us.ibm.com
Thu, 21 Jan 1999 14:46:31 -0500
From: jamsden@us.ibm.com
To: Chris Kaler <ckaler@microsoft.com>
cc: ietf-dav-versioning@w3.org
Message-ID: <85256700.006D445A.00@d54mta03.raleigh.ibm.com>
Date: Thu, 21 Jan 1999 14:46:31 -0500
Subject: RE: CHECKIN/CHECKOUT - Mutable resources and a call for consensus
Chris,
You're up pretty early! Must have had trouble sleeping if this thread got
you going.
I think there are a couple of misunderstandings that caused some of your
concerns. I'll try to clear them up. You may have to refer back to the
original document for context, but I didn't want to reinclude such a long
note. The numbers below correspond to the original note.
1. I don't have any problem with making support for mutable revisions an
option. I don't want to make support for immutable revisions an additional
option though. If a server supports DAV versioning, it supports immutable
revisions. It may in addition support mutable revisions. I just like to
limit the options where ever possible. In the "pool" scenario, its the
mutable header on checkin that would be optional.
3. We want predecessor/successor to always have well-defined, consistent
meaning that supports richer merging and configuration management
semantics. As you pointed out, these semantics cannot be guaranteed unless
the participants are immutable. So we want to reserve a relationship that
has these semantics and call it predecessor/successor as the conventional
meaning of these terms fits nicely. The "derived from" relationship is
included to support more flexible semantics and mutable revisions.
5. This is where I think there is some confusion. Given an mutable
revision, an author can either change it with PUT or PROPPATCH directly, or
check it out to create a new revision and check it back in. In the first
case, there is only one revision, and its state changes. In the second
case, there are TWO revisions with the derived from revision having the new
state, and the original revision is unchanged. This allows the DMS client
to choose if it wants a new revision (use checkout), or update the existing
mutable revision (PUT). So you don't need to checkout a mutable revision to
change it. This is orthogonal to the freeze/thaw issue. These methods could
still be applied to a mutable revision before it can be changed without
effecting the semantics of checkin/checkout.
This is also orthogonal to branching. Since you don't need to checkout a
mutable revision to change it, then branching isn't an issue. If the
revision is immutable, or if it is mutable and the author wants a new
revision (not an update of the existing revision), and you want to change a
non-tip revision, you'll need to create a new activity (which might be
implemented as a branch). Sorry, that sentance reads more complicated than
it is, but you get the point.
6. I think we are in agreement. I also think mutability is a property of
the resource, and its association with predecessors, successors, and
derivations. This is why I think mutability is established on checkin. When
you have a versioned resource checked out, you have a working revision, and
the relationship to its predecessor is not fully established. The mutable
header on checkin tells the server what relationship to create:
successor/predecessor, or derived from source/destination. It also
indicates as a result of the relationship semantics whether the revision is
mutable or not. Note that this information may be derived from the
relationship, and not be an attribute of the revision at all.
Again, I don't have any problem with servers disallowing mutable revisions.
7. [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
guaranteedto
be a physical one.
Ah, but the predecessor/successor relationship DOES change. The revision
you said was the predecessor no longer exists. This might be fine for a
spelling correction, but it a dangerous and missleading lie for many other
changes. Merge control is lost, configurations are no longer reproducable.
Hence the need to separate predecessor/successor relationships from derived
from relationships. Predecessor/successor means more than 2 is before 3 and
4 is after 3. That's what derived from says. Checkin doesn't change the
mutability, it establishes it. Mutability can never be changed once
established.
8. You're right, configurations can be used for more than just release
management. For example, setting the version selection rule in your
workspace. However, this is a case where the strongest semantic defines the
meaning. If configurations are ever to be useful for release management
(one of their primary uses), then they cannot ever contain mutable
revisions. We could introduce the notion of "mutable configurations" that
change as a result of updates to revisions in the configuration, but I
think this is totally unnecessary. Configurations have real value when
their integrity depends on maintaining the associations between their
member revisions. Otherwise, just use a collection.
9. Parallel development can be more trouble than its worth if there isn't
good support for merging activities. There are two problems: 1) what needs
to be merged, and when am I done, and 2) how do I merge a given resource.
By retaining the revision history and checking out resources in activities,
WebDAV can easily support 1). 2) requires resource-specific facilities and
should be out of scope for WebDAV. However servers can give the source and
destination revisions, as well as their least common ancestor: things that
are essential to any merge tool.
10. Again, it is not necessary to checkout a mutable revision to change it.
You might be confusing these semantics with Geoff's proposal which does use
checkout in this manner.
I could be easily convinced to include the freeze/thaw semantics, just
never on mutable revisions. They should only be a gesture, and not have any
semantic meaning. I just left them out due to my minimalist tendencies.
11. [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.
DMS systems wouldn't check things is as immutable, so there should never be
a need to thaw an immutable revision. So this doesn't seem like a
restriction.
12. These semantics make no assumption about either the protocol, or how
servers might implement them. I'm trying to stay as far away from those
discussions as possible so we can concentrate on the scenarios we want to
support, and the semantics of supporting them. However, I would assume a
workspace is a resource having content, likely expressed in an XML document
that would contain the version selection rule and a link to the current
activity, also a resource. We don't need to overload the property mechanism
for this, they could just be new, DAV defined resource types.
Protocol issues:
1. It is a revision and revision relationship problem, but one that is
established at checkin time. So mutability needs to be specified as part of
checkin.