Re: Version merging questions

   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