Nathaniel Smith <[EMAIL PROTECTED]> writes: > To make our life simpler, we always send stuff in such an order that > we can simply stream it straight to the db and consistency is always > maintained; that way we can simply hit "commit" at any time.
So the sender orders items with respect to the dependency graph such that any referenced items arrive before any items referencing them? > Well, merkle tries or the rsync algorithm I've been thinking about this for several days now, and it's probably fodder for a new thread. Can you explain how monotone uses Merkle Tr(e|i)es during synchronization? Specifically, what are the items or data stream being summarized by the hash tree? My first guess is the revision graph, flattened somehow, but feel free to correct and elaborate on that. > to make transmissions idempotent I can see how using hash trees avoids having to retransmit data already held on both sides, but I take idempotent to mean that transmitting the data (or doing anything) twice has no distinguishable effect as opposed to doing it only once. Did you mean "avoid sending more than we need to" or "don't worry if we send more than we need to"? > plus content-addressing This one has proved to be a stumper trying to find references on the Web, trying to avoid having to ask here. My best guess is that you're referring to using hash values for identity, so that the same content maps to the same identity value, making it easy to discover equal content. But the phrase also suggests being able to look something up with a special key. Can you clarify? -- Steven E. Harris _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
