- From: David G. Durand <david@dynamicdiagrams.com>
- Date: Sat, 5 Dec 1998 19:36:39 -0800
- To: w3c-dist-auth@w3.org
- Message-Id: <199812060336.TAA16451@dynamicdiagrams.com>
>From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com> > 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. This is a good point. A client modification could be wrong (because people get things wrong) but that's really not any less true of a server. What is true is that a server managed link will (by definition for a correctly functioning server) be consistent in terms of the _server's_ defined invariants. Correctness in the sense of user intention and meanings is not actually guaranteed for modifiable or non-modifiable predecessors. >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). right... >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. This does bring to mind one thing: for a change set system, there might well have to be more than one unmodifiable predecessor (for the same reasons that there is exactly one in a branch-based system). So maybe need to examine our implicit assumption that there is exactly one (as opposed to _at least_ one) unmodifiable predecessor -- David ------------------------------------------+---------------------------- David Durand dgd@cs.bu.edu| david@dynamicDiagrams.com Boston University Computer Science | Dynamic Diagrams http://www.cs.bu.edu/students/grads/dgd/ | http://dynamicDiagrams.com/ | MAPA: mapping for the WWW | http://dynamicDiagrams.com/minimapa
Received on Saturday, 5 December 1998 19:51:41 UTC