Re: Version merging questions

>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