Timeline

The sidebar was display:none below 800px, which is most of the time an embedded doc is read -- a panel, a phone, a split window. A 60-section reference with no navigation at all is worst exactly where scrolling costs most, and the rule was invisible because it only fires at widths you do not develop at.

Below 800px the rail becomes a compact index above the content, links flowing as wrapped chips rather than one per line. It is collapsed by default there: expanded, it pushed the page title a full screen down, so a reader met a wall of verb names before learning what the page was. The disclosure is hidden entirely on the wide layout, where the rail is always open and the control would be noise.

Verified in a real browser at 1400, 780 and 500 pixels: 70 index entries reachable at every width, against 1 before. check-in: 65fe7b9ec5 user: dmestas tags: trunk

The command reference and the caching write-up move into the tree as embedded documentation, which quarry serves on fossil's own /doc/VERSION/PATH route, already implemented in its api/register.go.

Fossil's www/embeddeddoc.wiki gives the reason to prefer this over the wiki, and it is the reason the pin below can exist:

The documentation files are versioned together with the source code files so it is always clear what version of the documentation goes with a particular release.

A wiki page cannot be pinned by a test; nothing ties it to a checkout. A tracked file can. reference_test.zig checks both directions -- a dispatched verb with no section, and a section naming no verb -- with a reviewed-exception list for sections that document an absence on purpose, which is what the export-fossil section is. The reference had drifted for weeks: grep, purge, config and trust all shipped undocumented, and nothing noticed because noticing needed a human to compare two lists.

The caching page's ladder is corrected while embedding it. It reported 641.9s / 58.3s / 0.31s; those were Debug numbers. Measured in the mode that ships: 29.63s full derive, 0.34s record-body replay, 0.04s image. Having a cache is worth 87x and the image a further 8.5x -- both real, neither 188x. Its footnote about a separate environment reporting 0.38s 'unreconciled' is resolved: same machine, optimized build. info also moved to the image since it was written, leaving branch and tag on the record-body rung. check-in: 269e24b3c3 user: dmestas tags: trunk

The image carries the active tag set now -- name, tagtype, optional value, per rid -- so tagsOf, branches, tagNamesMatching and activeTagValue all answer from either backing. Stored resolved: the derive has applied §5.1's cancel rule and §5.3's precedence before serialize runs, so nothing here re-judges either. That is what fossil does, where tagxref holds one row per (rid, tag) with propagation flattened in by tag_propagate at write time.

It subsumes the §5.2 override columns from the previous change; those are gone rather than kept beside a general mechanism that already holds the same bytes.

Two readers still went straight to tagxref and had to be routed: activeBranchValue and hasActiveClosed. Both answered plausibly on an image rather than refusing -- the first as a null-deref in a postcondition under safety and, with that assert compiled out, a different branch listing; the second as a listing quietly missing every (closed) marker.

tagNamesMatching keeps a per-backing arm on purpose. The derive holds a (rid, tag) map with no per-rid index, so walking rids and asking each for its tags is O(rids x map) there; sharing one loop cost 42s where two cost 0.37s. check-in: ce9e7a1cd4 user: dmestas tags: trunk

Every rule was paid for by a wrong answer that looked convincing: an issue filed against this repository proposed an architectural change on the strength of a 58s figure that was a bare-zig-build Debug number; the ~25x pack figure this file carried came from a --release=fast that was quietly building ReleaseSafe; a single run reported a 20% regression for a change that was a 3.7x improvement; and an optimization that won by 50x was erroring out on the first artifact and printing nothing.

It sits beside the build rather than in the wiki because each rule is only true of THIS build script -- bare zig build means Debug because of the line above it, and every --release resolves to the preference for the same reason. A page elsewhere would rot the day one of those changes and nothing would fail. check-in: 4e355fbfd1 user: dmestas tags: trunk

The default listing prints an ID per check-in and reads nothing else, yet it reconstructed and re-parsed every reachable manifest to find P cards. On a repository whose manifests inline the whole file set -- sqlite's are 2,219 F cards and 186KB each -- that is 6GB of text decompressed and parsed to answer a question that reads none of it.

Fossil does not do this. manifest_crosslink parses a manifest once and writes the edge to a persistent table:

CREATE TABLE plink(pid, cid, isprim, mtime, baseid, UNIQUE(pid,cid)); CREATE INDEX plink_i2 ON plink(cid,pid);

Every later traversal is an indexed read of it -- timeline.c's ancestor walk is a recursive CTE over plink and touches no manifest. The tell is fossil's parsed-manifest cache: MX_MANIFEST_CACHE is 6, and its comment says it exists for rebuild. Nothing on the read path needed more.

zit's derive holds the same relation, with the is_primary flag plink's isprim carries, and since #98 the zero-parse image carries it too, so this walk reads no artifact content at all. --long still needs D/U/C, so it stays on the reading walk.

log tip, min of repeated runs, warm, ReleaseFast:

libfossil 1.28s -> 0.02s libspatialite 4.81s -> 0.00s fossil 20.40s -> 0.11s tcl 40.05s -> 0.65s sqlite 62.90s -> 0.51s

Output byte-identical across all seven corpora.

WHAT MOVED: the reading walk re-hashed and re-validated every reachable artifact, so log doubled as an integrity check. It no longer does -- which is fossil's split, where validation happens at crosslink and test-integrity re-checks. zit verify is that verb, and the wrong-full-ID test now asserts verify catches what log stopped catching, so the coverage cannot go missing unnoticed. check-in: cc996c1af2 user: dmestas tags: trunk

info was the last of the three verbs held on the record-body rung, and it was held by one thing: amend --comment stores its override as a tag, and tagxref is empty on an image backing, so the fast path printed the manifest's original comment. On tcl that cost 58s to print one check-in.

The image carries the three display overrides now -- comment, user, date -- RESOLVED. The derive has already applied the cancel rule and mtime precedence by the time they are written, so the image stores the answer and never re-judges it, the same trade branch_id already makes with the §6.1 fallback. That is also what fossil does: tagxref holds one row per (rid, tag) with propagation flattened in by tag_propagate at write time, so its readers do group-bys rather than precedence.

activeTagValue now asserts derived backing instead of answering null there. It returned null for a caller that had a tag, which is the silent shape of wrong this whole issue is about; displayOverride is the image-safe door for the subset the image actually carries. check-in: 8c3abc36c7 user: dmestas tags: trunk

On tcl's tip zit ls drops from 58.3s to 0.31s: the derived state it needed was already in the cache, in the zero-parse image, and the verb asked for the record-body replay anyway.

Adjacency arrived in the image last change; what remained was every read that went around the accessors. events, its count, and store.count are all empty on an image backing, so a bound taken from them read zero and a branch value read from tagxref fell back to main_branch for every rid -- the section 8.4 walk then never left the branch and answered start:/root: with a check-in from somewhere else, exit 0 and no diagnostic. Those reads route through hasEvent, mtimeOf, hashOf, ridCount and eventsIter now, which name one enumeration order for both backings rather than inheriting insertion order from one of them.

info stays on the full derive: amend --comment stores its override as a tag, and the image carries no tag tables, so on the fast path info printed the manifest's original comment. An existing test caught that the moment the verb moved; branch and tag stay behind for the same reason. check-in: 2772dd3942 user: dmestas tags: trunk

walkLog reconstructed every manifest with log.content, which walks the delta chain from scratch. Check-in manifests are routinely stored as deltas against their neighbours, so the same base chain was re-resolved once per check-in -- work that grows with the history behind a node rather than with the node. Per-check-in cost climbed with repository size (0.5ms on libfossil against 2.2ms on sqlite) instead of staying flat.

Every other read path in this file already took #84's PlaintextCache; this one did not. Output is byte-identical -- contentCached is the same bytes, only less work.

log tip, min of repeated runs, warm, ReleaseFast:

pikchr 0.14s -> 0.04s wapp 0.05s -> 0.01s libfossil 1.26s -> 0.34s libspatialite 4.69s -> 2.28s fossil 19.36s -> 7.24s sqlite 59.70s -> 23.81s tcl 38.29s -> 5.99s

The image held mtimes, hashes, branch ids and the symbol table but not the parent/child relation, which is why every verb needing ancestry re-derived the whole log on open. Six CSR columns carry it now, both directions with the primary flag -- primary-parent selection and merge-edge skipping both read it, so an image without it answers wrongly rather than refusing.

The two backings hold the same relation in different shapes, so edgesOf hides which one a caller got, and the equivalence test compares them in order with a guard that fails when the corpus has no edges to compare.

Behaviour-neutral: no assert relaxed, no verb moved. Freeing those needs an events equivalent as well -- resolve reads self.events directly, and that table is empty on an image backing. check-in: 82de6f83d0 user: dmestas tags: trunk

Measured on wapp warm, modes interleaved and repeated: pack is ~8.5s fast, ~9.5s safe, ~10.7s small, and the read path is 0.31/0.33/0.36 with leaves at 0.01s in all three. So fast buys ~12% on writes and nothing measurable on reads.

The '599ms fast against 15.2s safe, ~25x' this file carried reproduces in neither the ratio nor the absolutes; the delta encoder's search was reworked since it was taken. Left uncorrected it would have justified almost any correctness cost, which is the expensive kind of stale number to leave in a comment that decides the shipped build. check-in: 6181a57e0c user: dmestas tags: trunk

zit ships ReleaseFast, so --release names it. This reverses the ReleaseSafe pin; pack runs ~25x faster and read verbs are indistinguishable between the modes (ls over tcl's 300MB store is 0.31s fast against 0.33s safe, leaves 0.01s in both).

The cost is real: over a thousand std.debug.assert calls compile to nothing, so release_assert_test.zig stops being belt-and-braces and becomes the thing keeping an assert from standing in for validation of untrusted input. Its rationale is rewritten around that.

Stating a preference makes it the ONLY reachable release mode, which the old comment got wrong: it documented --release=fast as an escape hatch from the ReleaseSafe pin, and that flag produced a ReleaseSafe binary anyway -- safety strings present to prove it. Anything benchmarked through it before now measured the checked build. The ci pin moves from 'keeps assertions alive' to 'the mode is stated, not left to whoever packages', which is the part that survives the reversal. check-in: da904fbe1c user: dmestas tags: trunk

smoke is the only lane that runs a real fossil against zit, so runners on different fossils make the conformance claim mean a different thing on each -- a regression against the newer can pass on the older, and newer-only behaviour reddens the older for something that is not a defect. Both are silent, because the version is printed hundreds of log lines before the failure it explains. fossil sqlite3 quoting its output on 2.26 but not 2.28 cost three round trips that way. The printed line stays; the release notes still need it. check-in: ab3a1983cb user: dmestas tags: trunk

-S reports the check-ins where the occurrence count of PATTERN changed, -G those where a changed line mentions it. A string added once and deleted later is two lines, where plain grep reports every version that held it in between.

The issue expected this to need a diff per revision. It does not: a path whose blob hash matches its parent's cannot have moved either answer, so the walk compares F-card hashes and reads only the blobs that changed. Deletions are picked up from the parent side, which a walk over the child's files alone would miss.

Merges compare against the primary parent, as git log -S does; counting against every parent reports one appearance twice. check-in: 28c48bb3f7 user: dmestas tags: trunk

The runner on 2.26 returns the check-in uuid wrapped in single quotes where 2.28 returns it bare, so the name handed to fossil tarball could not resolve -- and the failure named the hash, which reads like a missing check-in rather than a quoting difference. The harness strips to hex and then insists on a 40- or 64-character hash, so a future output change is refused by name here instead of failing two commands later. The CI step no longer runs its own copy of the query; one place for this to go wrong is enough. check-in: f37a155d45 user: dmestas tags: trunk

One runner carries fossil 2.26 where the others carry 2.28, and 2.26 refuses options before the positionals -- fossil documents 'tarball VERSION OUTPUTFILE [OPTIONS]' and 2.28 merely tolerated the other order.

The reason that took a full CI round trip to find is the second change: a failure said 'see $WORK/x.log' on a machine nobody can log into. It now prints the log, so fossil's own sentence reaches the build output. check-in: e492130985 user: dmestas tags: trunk

The discovery message tells the operator to name the repository with -R. For a -R failure that advises supplying the flag already supplied, and it reads the same whether the path was mistyped or simply holds no repository -- so a stale path in a script looked like a bug in the verb. Reported against tarball; every -R verb had it. One reporter, routed through all nine resolveRoot call sites; the no-flag discovery message is unchanged. check-in: 10a1236a7a user: dmestas tags: trunk

The runners have no unzip, so the harness exited 2 for a missing tool and the step failed on its own coverage guard instead. Adding a third tool to the battery for one step is the worse trade: python3 is already required here, and ZipFile.extractall drops modes and symlinks -- the exact defect this differential exists to catch -- so the external attributes are applied explicitly rather than trusted to an extractor. check-in: 2420f6fb88 user: dmestas tags: trunk

archive-fossil-diff.sh writes the per-format comparison to stderr, but the step piped only stdout into diff.log, so the 'kinds compared' line the coverage guard greps for was never in the file -- it counted 0 on every platform and the step could not pass.

pipefail with it: the pipeline was taking tee's status, so the differential's own failure, including its exit 2 for a missing tool, was swallowed and only the guard could ever fail this step. check-in: 98243aad6a user: dmestas tags: trunk

Removes a check-in and the blobs only it introduced, into a local graveyard that purge undo restores and purge obliterate empties.

The drop set is (seed + reachable(seed)) minus reachable(everything retained), so a blob a surviving check-in still names is never freed -- dropping it would create a phantom rather than reclaim anything. Only leaves go, judged over the whole named set: purging a parent alongside its child is accepted, purging it alone is refused.

Reuses shun's rewriteAndSwap and records no tombstone: a purge is local, so content that already synced comes back from a peer. The help says so and points at shun. check-in: 8536f59fba user: dmestas tags: trunk

A blob's plaintext length is already in every frame kind -- a zlib container states it outright, a delta carries it in its own header -- so --size reports one without resolving a chain. The binary verdict cannot be had that way (a NUL may be the last byte), so --long still reads every blob and keeps its exact columns.

The larger cost was neither: resolveHexPrefix scanned the whole store per file to resolve a full-width name the digest index answers outright, which slowed plain ls too. On tcl's tip --long drops 167s to 93s and --size costs what plain ls costs. check-in: 3b7e8c7569 user: dmestas tags: trunk

Unlike S10, which its own comment notes survives deleting the server's admission check, this one genuinely exercises the decision: the violating file is ordinary new content fossil pushes because it is new.

Records the limitation in the header: fossil exits 0 after printing the refusal, so the assertions are on the store and on fossil's output rather than its exit status. zit push exits 1. check-in: abc41cae82 user: dmestas tags: trunk

#81's predicates bind a checkout; nothing stopped a push from a clone that never adopted them, or from stock fossil. Fossil cannot close this at all -- its hooks are before-commit (client-side) and after-receive.

The policy is the SERVER's, resolved per round from its own settings, never from the artifacts arriving: a push carrying its own policy would otherwise arrive bearing permission to land. Only inspecting rules cross the wire; before-commit has no server-side counterpart.

A push sends artifacts by hash and only a manifest names paths, so the walk is manifest-first -- the policy gates what becomes REACHABLE, not what bytes transit. Decided before ingest, so a refusal stores nothing, and the whole round is refused rather than half of it.

Verified against fossil 2.28: it prints the refusal text verbatim and lands nothing. Note it exits 0 while doing so, where zit push exits 1. closed check-in: e091f2ac80 user: dmestas tags: push-policy

zit had no content search at all -- not git's pickaxe, not fossil grep's file-scoped walk. This is the latter: each named file's stored versions newest-first, every version whose content contains PATTERN reported with line numbers. A run of check-ins that never touched the file shares one blob and reports once.

PATTERN is literal; zit carries no regex engine and git log -S is literal for the same reason. Working-tree search stays ripgrep's job -- what only zit can do is read content that is not on disk.

A version the store cannot produce is counted and reported on stderr, not skipped: a search that quietly examined less looks like one that found nothing. Exit 0 found, 1 not found. check-in: a0ab591180 user: dmestas tags: trunk

Selection, top-level directory, reproducibility, and the refusal to write a partial archive are shared with tarball whole; only the container differs. Zip's header carries the size and CRC, so a member is compressed before its header is written, and deflate is used only when it makes the member smaller. Modes live in the central directory's external attributes, which is where a reader looks and where an executable silently becomes 0644 if you get it wrong -- so the fossil differential compares both formats now. check-in: c454de8df9 user: dmestas tags: trunk

Comparing zit to itself cannot catch a wrong permission bit -- writer and reader agree in the same direction. Fossil is an independent witness that already gets it right, so the harness unpacks both archives and compares member set, modes, and contents. It found one: -R was dropped at dispatch, which every test missed by running inside a checkout. Fossil versions symlinks where zit add still refuses them, so an imported corpus is also what finally exercises the l-perm path. check-in: 96a6d46d19 user: dmestas tags: trunk

The effective-set walk already resolves sub-manifests and delta chains in canonical order, so this is that walk with an archive writer. Members carry the F card's permission, so an executable stays executable. Two runs of one version are byte-identical: history supplies the order and the timestamps, and no uid, gid, or build host is recorded. A file the store does not hold is refused by name -- a partial archive looks exactly like success. check-in: 580d0691c7 user: dmestas tags: trunk

Plain tag listing now reflects only singleton symbolic release names, while raw listing preserves complete repository tag state.

Refs ticket a679b1197b61127930f7e2a6478145c561dd54cc. check-in: 24356ebb90 user: dmestas tags: trunk

Plain tag list now shows only singleton symbolic names globally and on a check-in, excluding branch machinery, raw properties, and propagating tags. Raw listing preserves every active tag, stored prefix, and value.

Add a tag-type-filtered repository-state query and end-to-end coverage for mixed singleton, propagating, raw, and branch tags.

Refs ticket a679b1197b61127930f7e2a6478145c561dd54cc. closed check-in: 41852f0a9e user: dmestas tags: fix-tag-list-release-filter

ls --long adds size, the F card's permission token, and text/binary. The permission is the fact no other verb can supply -- it lives in the manifest, and the blob it names does not know it is executable -- so a listing could not mark executables and mis-rendered symlinks. --under bounds the listing to one directory, which is also what makes --long's per-file content read affordable.

log --long adds each check-in's timestamp, user and comment. log CHECKIN PATH already selected the check-ins touching PATH; emitting only hashes meant a file-history page cost a subprocess per row.

Both are opt-in; the default outputs are byte-identical. A blob the store cannot produce reports 'absent' rather than a zero-byte text file. closed check-in: f01eb5b6a0 user: dmestas tags: quarry-support

Longest match across both polarities decides coverage, so the verdict alone cannot say why a file is missing. The member prints bare so it pastes into zit cone remove. Exits 0 when every path is covered, 1 when any is elided. closed check-in: 3cb62134a3 user: dmestas tags: sparse-cone

Both are opt-in: an unset glob is no opinion, not refuse-everything, so a repository that never set one commits exactly as before. Set binary-glob to *.png and PNGs are the binaries the project expects, so a stray .o is refused. Neither runs code, so unlike before-commit they bind a fresh clone with no consent step -- that asymmetry is why they exist.

The check gates what a commit INTRODUCES: an all-files commit re-captures every managed path, so classifying unchanged content would make declaring a glob block every later commit until the whole tree already conformed. Comparing against the parent's blob grandfathers inherited files, per content rather than per path, so editing one re-checks it.

--no-checks waives it, the same flag that waives before-commit. check-in: 2711adbb03 user: dmestas tags: trunk

project-code and hash-policy join stat's fields, and stat joins the -R family it was refused for a plumbing reason rather than a policy one. A consumer needing the project code had to find a free port, spawn zit serve, poll for readiness, POST a clone container and scrape the push card -- a subprocess and a listening socket per repository -- because the value was reachable only by speaking the sync protocol to a server you started yourself.

The no-checkout diagnostic said 'no .zit found' in directories where .zit was sitting right there; discovery looks for .zit-checkout, so it now says that and names -R as the way in. closed check-in: cd748a57c2 user: dmestas tags: project-code

keep-glob protects files clean must never delete while extras still lists them; manifest becomes a project setting driving build stamps. Both resolve across the tier chain, so a tracked .zit-settings file clones with the code.

before-commit splits declaration from consent (#82): the project ships the check as a tracked file, zit trust records the SHA-256 this checkout agreed to run. Cloning executes nothing, and an edit revokes consent by itself because the record pins content, not a flag. Non-zero exit aborts before anything is minted.

zit config pull shun is fossil's explicit request side; carriage stays clone-time otherwise so no peer can suppress content here on its own say-so.

Storage gains one keyed-string block: unknown keys are skipped by length, so the next string setting needs a key rather than another shape tag. Existing frames are unchanged.

clean-glob is deliberately absent: it means never-prompt and no-undo, which zit clean already is. check-in: 998dbf9d43 user: dmestas tags: trunk

Fossil distinguishes an absent token from an empty one positionally: `C` LF has none and is rejected, `C` SP LF has one empty token and is a present, empty comment. zit implemented §4.2's `token = 1*tchar` literally and rejected the empty form on C and J, which drops the whole artifact — every ticket change with an empty field, every check-in with an empty comment. T and U were already right.

Two tests asserted the old behaviour and now assert the corrected one; a third pins the writer, since --submanifest re-mints every manifest. The RFC text is unchanged; docs/rfcs/erratum/ carries the correction. closed check-in: 5ccb138e6d user: dmestas tags: empty-trailing-token

Carrying the /shun config group means a fossil clone records the artifact as suppressed instead of holding a phantom for it. That is the better end state: a phantom is something fossil goes looking for, so the next sync with any third party would undo the takedown.

S9 asked for the phantom specifically and so went red. It now asks fossil's own shun table and REQUIRES the row — tolerating the phantom would leave the scenario unable to notice the carriage regressing. The phantom probe stays as a diagnostic that tells a lost row apart from a served artifact. check-in: 7c656e4718 user: dmestas tags: trunk

Profiling the post-memo stream put 59% in artifact.verify and 38% in reconstruction, so the parallel target is verification, not reconstruction: reconstruction is what the plaintext memo made sequential-friendly, and fanning it out would contend on that cache.

Reconstruction stays single-threaded; a bounded batch is hashed by workers walking disjoint strides, then emitted in order. Workers touch no store, no cache and no allocator, so there is no queue, lock or atomic — join supplies the ordering. libfossil 2.35s -> 1.37s wall, byte-identical output. closed check-in: 4b2fceeacd user: dmestas tags: frames-parallel

clearsign and pgp-command join zit settings as repo-local values fossil never propagates: pgp-command is a command line this machine executes, which fossil classifies sensitive for that reason. Config frame gains shape v4 for the command string; clearsign rides the existing flags byte. Precedence is ZIT_PGP_COMMAND, then the setting, then fossil's default.

zit serve now answers reqconfig for a named group, and clone requests and adopts /shun. A clone that dropped the table would re-accept content its origin was ordered to remove on the next sync with any peer; the #73 scale run also traced 12 spurious phantoms to the same loss. Verified both directions against stock fossil 2.28.

scripts/roundtrip-fossil.sh is the fossil -> zit -> fossil differential, run in CI on a built corpus: zig build e2e can only spawn zit, so nothing in the Zig suite can assert a stock fossil accepts what zit served. check-in: 57a9e0fc6b user: dmestas tags: trunk

frames was the one bulk reader still calling the uncached content(), so a delta base was reconstructed once per referencing delta rather than once per run — superlinear work against a linear stream, on corpora that are ~90% deltas after a fossil import.

libfossil (17,449 artifacts): 12.4s -> 2.34s real, 12.0s -> 2.25s user. Output byte-identical, peak RSS down 362MB -> 314MB. memoize_undeltaed stays off: the sweep reads each artifact once, and bases are memoized regardless of their own frame kind, which is the win. closed check-in: 2e3bb0b9db user: dmestas tags: frames-memo

technote add gains --comment (the C card a timeline renders as the note's title, unattachable by any later verb) and repeatable --tag, minting T +sym-NAME * sorted ascending as fossil writes it. forum post and reply gain --mimetype, matching wiki commit's spelling. Empty titles, repeated tags, and whitespace tag names are refused.

First CLI-level coverage for either verb: #76 shipped them tested only at the artifact layer. closed check-in: 21f6efdd1c user: dmestas tags: record-cards