diff options
-rw-r--r-- | tvix/castore/docs/blobstore-chunking.md | 4 | ||||
-rw-r--r-- | tvix/castore/docs/data-model.md | 6 | ||||
-rw-r--r-- | tvix/castore/docs/why-not-git-trees.md | 2 | ||||
-rw-r--r-- | tvix/eval/docs/bindings.md | 2 | ||||
-rw-r--r-- | tvix/store/docs/api.md | 2 |
5 files changed, 8 insertions, 8 deletions
diff --git a/tvix/castore/docs/blobstore-chunking.md b/tvix/castore/docs/blobstore-chunking.md index 49bbe6927554..df3c29680257 100644 --- a/tvix/castore/docs/blobstore-chunking.md +++ b/tvix/castore/docs/blobstore-chunking.md @@ -73,10 +73,10 @@ This means one only needs to the root digest to validate a constructions, and th constructions can be sent [separately][bao-spec]. This relieves us from the need of having to encode more granular chunking into -our data model / identifier upfront, but can make this a mostly a transport/ +our data model / identifier upfront, but can make this mostly a transport/ storage concern. -For the some more description on the (remote) protocol, check +For some more description on the (remote) protocol, check `./blobstore-protocol.md`. #### Logical vs. physical chunking diff --git a/tvix/castore/docs/data-model.md b/tvix/castore/docs/data-model.md index 2df6761aae8f..5e6220cc23fa 100644 --- a/tvix/castore/docs/data-model.md +++ b/tvix/castore/docs/data-model.md @@ -15,8 +15,8 @@ a directory. All three message types have a `name` field, specifying the (base)name of the element (which MUST not contain slashes or null bytes, and MUST not be '.' or '..'). -For reproducibility reasons, the lists MUST be sorted by that name and also -MUST be unique across all three lists. +For reproducibility reasons, the lists MUST be sorted by that name and the +name MUST be unique across all three lists. In addition to the `name` field, the various *Node messages have the following fields: @@ -27,7 +27,7 @@ A `DirectoryNode` message represents a child directory. It has a `digest` field, which points to the identifier of another `Directory` message, making a `Directory` a merkle tree (or strictly speaking, a graph, as two elements pointing to a child directory with the same contents would point -to the same `Directory` message. +to the same `Directory` message). There's also a `size` field, containing the (total) number of all child elements in the referenced `Directory`, which helps for inode calculation. diff --git a/tvix/castore/docs/why-not-git-trees.md b/tvix/castore/docs/why-not-git-trees.md index fd46252cf55c..4a12b4ef5554 100644 --- a/tvix/castore/docs/why-not-git-trees.md +++ b/tvix/castore/docs/why-not-git-trees.md @@ -48,7 +48,7 @@ The git tree object format uses sha1 both for references to other trees and hashes of blobs, which isn't really a hash function to fundamentally base everything on in 2023. The [migration to sha256][git-sha256] also has been dead for some years now, -and it's unclear how a "blake3" version of this would even look like. +and it's unclear what a "blake3" version of this would even look like. [bao]: https://github.com/oconnor663/bao [blake3]: https://github.com/BLAKE3-team/BLAKE3 diff --git a/tvix/eval/docs/bindings.md b/tvix/eval/docs/bindings.md index 2b062cb13d87..17867acfe9f9 100644 --- a/tvix/eval/docs/bindings.md +++ b/tvix/eval/docs/bindings.md @@ -62,7 +62,7 @@ This is done by compiling bindings in several phases: At the end of this phase, we know the stack slots of all namespaces for inheriting from, all values inherited from them, and all values (and - optionall keys) of bindings at the current level. + optionally keys) of bindings at the current level. Only statically known keys are actually merged, so any dynamic keys that conflict will lead to a "key already defined" error at runtime. diff --git a/tvix/store/docs/api.md b/tvix/store/docs/api.md index 01e72671a743..c5a5c477aa17 100644 --- a/tvix/store/docs/api.md +++ b/tvix/store/docs/api.md @@ -5,7 +5,7 @@ This document outlines the design of the API exposed by tvix-castore and tvix- store, as well as other implementations of this store protocol. This document is meant to be read side-by-side with -[castore.md](../../tvix-castore/docs/castore.md) which describes the data model +[castore.md](../../castore/docs/data-model.md) which describes the data model in more detail. The store API has four main consumers: |