A namespace node: `["ns", [[name, [hashes]]...], [[child, nodeHash]...]]`, both lists sorted by name. Where a name shows a definition with other text than it was first stored with (its comments, layout or doc changed), a fourth list says which version: `[[name, hash, textHash]...]`, sorted by name and hash. A node without one is written, and hashed, as before there were text versions.
How a definition reads: its code as written (comments, layout, names spelled as then) and its doc. None of it is in its hash, so one definition can have several; each is kept by its textHash.
A text as the codebase keeps it: a long one zstd-compressed, as bytes, in the column that would hold it (a definition's code and source, metadata, a namespace node); a short one as itself. unpacked reads either.
Lay a codebase's tables out as this tcm does, taking `LAYOUT_STEPS` in turn, in the caller's transaction: the layout it was in and is now, or undefined if it was in this one already.
LAYOUT_STEPSRecord<string, { to: string; step: (db: DatabaseSync) => void; }>
How a codebase in an older table layout moves to this tcm's (`LAYOUT`): by the layout it's in (its `layout` setting), the step that moves it on, and the layout that leaves it in. `tcm migrate` takes them in turn until it's this one's; a layout with no step from it (a newer tcm's, or one from before there were steps) can't be moved.
A message as given (`-m`, a tool's `message`): line endings as `\n`, trailing spaces and blank lines at either end taken off. Nothing left is no message.
How a history entry's `command` column holds what made it: the label of the command (`update lib.f`), then, after a line break, the message it was given (`-m`), if any. One column, so the message goes wherever the entry does (a push, a pull, a migration), with any tcm; it's in no hash, so it can change without changing history.
A signature with other names for what it names: `renames` maps the name a definition was made as (how a signature prints it) to the name to show. Only types and values are renamed, not property or parameter names (`{ Foo: Foo }` keeps its key), a qualified name's members, or what's in a string literal type.
Layout step: patches kept whole for each branch (layout 8f648138…) go into sets branches share (85655ca2…). Main's are one set, and every branch reads a set of its own over it, holding where it differs (a patch main doesn't have, or one hiding a patch of main's it doesn't have); or a set of its own alone, where that's less.