- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Fri, 4 Dec 1998 22:57:22 -0500
- To: ckaler@microsoft.com
- Cc: muniz@inf.puc-rio.br, w3c-dist-auth@w3.org
From: Chris Kaler <ckaler@microsoft.com> I guess I think of it a little different. There is an "un-modifiable" list and a "modifiable" one. The first is managed by the server and represents what the server knows to be correct. The second is managed by the user and could be totally wrong. Just to make sure I'm not missing something, in what sense does the server know that the unmodifiable successor arc is more "correct" than the modifiable successor arcs? In either case, this is just something that the client asserts at checkin time, with no way for one to be more "correct" than the other. The only difference is that one is not modifiable (to allow for some server side storage optimizations), while the rest are modifiable. When the server does the merging with no intervention from the client (such as in some change-set systems), then it is true that the server "knows" that these merges are true wrt its auto-merging semantics, but that's not the case for a new revision based on a "check-in" (which is the only mechanism for creating new revisions that we are currently supporting in the protocol). I think both of our points are valid and true and that we are essentially saying the same thing. I don't think this point affects the protocol at all (except for the minor issue of whether the "predecessor" property contains both the modifiable and unmodifiable predecessors). I believe though that it is an important point for understanding the semantics of "merging" in the protocol, because if it is a "correctness" issue, then the client has to make sure to make the umodifiable successor the "correct" one, while if it is just a server storage optimization, than the client can just arbitrarily pick which of the contributors to the merge will get the unmodifiable link. Cheers, Geoff
Received on Friday, 4 December 1998 22:58:03 UTC