docs(tvix): fix some typos across various documents
Fix some typos found while reading various documents, mostly those relating to the castore. Here is a summary of the edits. - fix broken link between documents in the store and castore directories - clarify expression in castore's data model document that indicates that the *name* of each child node of a directory must be unique across all three lists of children - add missing closing parenthesis in castore's data model document - replace "how" with "what" in the phrase "unclear how a ... would even look like" in castore's why-not-git-trees document - remove unnecessary articles in castore's blobstore chunking document - add missing "y" to "optionall" in eval's compilation of bindings document Change-Id: I1997ea91bb4e9c40abcd81e0cde9405968580ba6 Reviewed-on: https://cl.tvl.fyi/c/depot/+/11763 Tested-by: BuildkiteCI Reviewed-by: tazjin <tazjin@tvl.su>
This commit is contained in:
parent
4ed397ad00
commit
23e0973cdf
5 changed files with 8 additions and 8 deletions
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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:
|
||||
|
|
Loading…
Reference in a new issue