From: email@example.com To: Chris Kaler <firstname.lastname@example.org> cc: email@example.com Message-ID: <85256700.006D445A.firstname.lastname@example.org> 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.