design: Describe sedimentree traversal in detail #147
Conversation
alexjg
force-pushed
the
sedimentree-design-detail
branch
from
eef272d to
49afcd0
Compare
Co-authored-by: Brooklyn Zelenka <[email protected]> Signed-off-by: alexjg <[email protected]>
issackelly
left a comment
issackelly
left a comment
There was a problem hiding this comment.
I just read the complete before and after versions of this doc. I know you didn't ask for a review but only one thing stood out at me as a layperson trying to bring up my context window.
|
|
||
| Stating from `b` we still have `b,a` and from `e` we still have `e,c,a` but now we also have `d` as a loose commit. | ||
|
|
||
| There is one detail remaining. Where do we start our traversal from? When we start from the root it is easy as there is only one root, but starting from the heads of the document there are many options. To solve this we actually run the traversal starting from each head - that is, instead of having a single traversal over the graph, we have one traversal for each head. For Automerge documents this is not a huge problem because most documents are tall and narrow, so even with many heads most traversals consist of duplicate chunks. |
There was a problem hiding this comment.
What makes a document tall and narrow? I think it's another way of saying "the documents we see often have a long history and a small number of complicated merges, regularly converging quickly and then continuing". Is that right?
This description is immediately after several "left to right" representations but the one at the top of the section is tall and narrow. https://github.com/inkandswitch/keyhive/blob/3322be26a22937cdf27573f8683f737430832f55/design/sedimentree.md#terminology
The details of how to traverse a commit graph in order to produce the sedimentree chunks we need is a little subtle I think. In this PR I've described it in pseudocode. I also renamed "strata" to "chunk" in a bunch of places and also "level" to "depth". This matches terminology we're using in the implementation.