| Comment: | release: put the manifest assembler in the tree
release-manifest.json is the authoritative record of a release -- checksums, targets, qualification -- and nothing that produced it was in the repository. Its source_tree_sha256 had to be reverse-engineered from published output to cut 0.2.0: sha256 over 'sha256 path' lines sorted BY LINE, so by hash, which is the sha256sum | sort | sha256sum idiom. The release whose manifest nobody could check is the one carrying false fields. 0.1.3 labelled a native build x86_64-linux-musl and claims 104 source files against a tarball holding 93. The script re-verifies every archive against its own metadata fragment before describing it as qualified, and reproduces the published 0.2.0 manifest exactly. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
520e388d6a8a484dd309e9ff35ceaaa3 |
| User & Date: | dmestas on 2026-08-19 17:45:07.882 |
| Other Links: | manifest | tags |
|
2026-08-20
| ||
| 19:17 |
repostate: index the two tag lookups the cache serializer loops over
serialize called tagsOf per rid and resolveName per symbol, each a full tagxref scan -- O(rids x rows) and O(symbols x rows). A one-check-in append cost the next reader 42s on a 42K-check-in store (#107); now 0.8s, and a full derive drops 74s to 21s. tagsOf routes through the existing rid_tags index; resolveName gets the inverse tag_rids index, maintained by the same helper pair so the two stay precise together. Selection semantics unchanged. check-in: 0aa75ac13d user: dmestas tags: trunk | |
|
2026-08-19
| ||
| 17:45 |
release: put the manifest assembler in the tree
release-manifest.json is the authoritative record of a release -- checksums, targets, qualification -- and nothing that produced it was in the repository. Its source_tree_sha256 had to be reverse-engineered from published output to cut 0.2.0: sha256 over 'sha256 path' lines sorted BY LINE, so by hash, which is the sha256sum | sort | sha256sum idiom. The release whose manifest nobody could check is the one carrying false fields. 0.1.3 labelled a native build x86_64-linux-musl and claims 104 source files against a tarball holding 93. The script re-verifies every archive against its own metadata fragment before describing it as qualified, and reproduces the published 0.2.0 manifest exactly. check-in: 520e388d6a user: dmestas tags: trunk | |
| 16:58 |
release: prepare zit 0.2.0
The 0.1.x line grew from 38 dispatched verbs to 61, gained the sub-manifest dialect, and grew a layered derived-state cache. 0.1.4's notes mention sub-manifests once and never say cache, so the notes here cover that machinery rather than only what changed since 0.1.4. check-in: 09e80bc9ef user: dmestas tags: trunk, version-0.2.0 | |