Timeline

The repo nav's width was a function of its numbers — tk's 25557 and 5809 made a visibly different nav from a small repo's, wrapping to three lines on a phone. Counts go compact (25K, 5.8K, 1.2M, four characters max) with the exact figure in the badge title, and each entry is a pill rather than a word beside a loose number. Nav width is now identical across repositories.

Separately: sqlite has wiki pages named after check-in hashes, 40-char unbreakable tokens that pushed the page 300px past a phone viewport. main now breaks over-long words; pre keeps its own scroll. check-in: 15c39013de user: dmestas tags: trunk

Three fixes for one screenshot. The icons were CSS masks with inline data: URIs — valid in Chrome, invalid under iOS Safari's stricter parsing, so every icon rendered as a grey block. Now an SVG sprite of six Octicons (MIT, ledgered); no encoding to get wrong.

Alignment needed real table columns. CSS grid aligns within one grid, so a per-row grid gave every row its own widths and nothing lined up. Measured: stat cells now share right edges across rows exactly.

And the description spans the full row instead of sitting in column one, which had made that column as wide as the longest sentence and pushed the numbers off a phone. No horizontal scroll at 320-1280px; the mirror column drops below 30rem. check-in: 60e5e5ebb6 user: dmestas tags: trunk

A sentence of stats is a different width in every row, so nothing lines up and the column is hard to scan. Four fixed slots — check-ins, contributors, mirror freshness, last activity — each an icon and a number, in a grid so the numbers align down the page.

Durations go compact (34m, 12h, 3d) for the same reason; the exact instant stays in the title and datetime. Every badge keeps a title, because an icon alone states nothing. check-in: 7bf20af78a user: dmestas tags: trunk

An aggregator listing showed whatever the last commit happened to say — written for people already in that repo's context, the widest thing in the row, and on a phone one entry filled the screen. GitHub and Forgejo list description and activity and neither shows a commit message.

Replaced with what a stranger can use: last activity, check-ins, contributors, and mirror freshness. The last is there because mirroring created an ambiguity — a repo quiet upstream and a mirror failing for a week look identical if all you see is 'last activity'.

Contributors rides the memoized Counts, so it costs nothing per request. check-in: 012cdff6c9 user: dmestas tags: trunk

Removing a repository's disk space meant going to the shell and doing it without quarry knowing, which is worse than quarry doing it. Deletion now purges the store, the derived index, and every forge row keyed to the repository — grants, sync users, mirror, webhooks, CI records — in one transaction, so a new repository of the same name cannot inherit somebody's credentials.

Two brakes. confirm must equal the name: a yes/no prompt is answered reflexively, typing the name requires having read which repository is about to go. And the store is removed ONLY when it lives under this node's repositories root — quarry serves stores it did not create, and this forge runs on a corpus of exactly those, so deleting one named by --repo would destroy a checkout somebody else manages. Verified: the attempt on pikchr refuses and says to unregister instead. check-in: a8d2831bf4 user: dmestas tags: trunk

A repository with no check-ins has an unborn trunk, so the timeline, the file tree and every clone instruction have nothing to point at. Optional README, license (MIT or BSD-2) and .zitignore give it a born trunk, which is why GitHub offers the same three at creation.

The copyright line is left as <copyright holder> rather than filled with the account name: a copyright naming the wrong person is worse than one that is visibly unfinished, and an account is a login, not a legal entity. Seeding is refused on a clone, which arrives with its own history, and paths are checked against the repository root before anything is written. check-in: c5b6d979e2 user: dmestas tags: trunk

The front page rendered every repository unsorted and unbounded — the same shape that made the timeline unusable, and it is at 23 now. Adds a name filter, sort by name, recent activity or size, and a limit, with Total alongside Count so a page can say '5 of 23'.

Sorting happens BEFORE the limit. The other order gives an arbitrary subset in the right sequence, which reads as correct and is not.

Activity comes from the event table's index — one walk stopping at the first row — so the column that makes a forge listing worth reading costs nothing.

Adds repo.get, so the settings page and the CLI stop scanning the whole listing to read one repository's settings. check-in: 4a3165db34 user: dmestas tags: trunk

repo.update replaces repo.visibility and applies a repository's settings whole — a settings form submits every field it manages, so partial-update semantics would only add a way for the two to disagree about what absent means. The CLI reads current settings before writing, so 'repo private' no longer blanks the description.

A settings page at /r/{repo}/settings, admin-gated, and the description now appears on the repository itself rather than only in the listing: a reader arriving from a link otherwise sees nav and a file tree and no statement of what the project is. check-in: a41b410958 user: dmestas tags: trunk

Visibility on the registry, gated at every read path: pages, API, search, file reads and the sync endpoint all answer 404 for a repository the caller may not see. 404 and not 403 — a 403 confirms the repository exists, which is the one thing a private repository must not confirm.

The listing filters by visibility too. A list that names a private repository has leaked it whatever the page then refuses to show.

The gate lives in Deps.repoFor, where d.repo already resolved the store, so a new op cannot forget it. The API router now resolves identity for ANONYMOUS ops as well: a read op that never looks at credentials cannot tell a repository's own collaborators from strangers, and would lock them out of their own repository.

Two faults found while verifying. Repositories named by --repo had no registry row, so taking one private updated nothing and reported success — a security control that claims to work while doing nothing. They are recorded now, and SetRepoVisibility refuses a name it does not hold. Second, the sync path was ungated: a private repository whose pages refuse anonymous readers while zit clone hands over every artifact is not private.

Verified: anonymous and unprivileged accounts get 404 everywhere and a short list; a collaborator with read sees it; admins see everything. check-in: f88e97a9fd user: dmestas tags: trunk

Six ops (account.list/add/passwd/delete/grant/revoke, admin) plus quarry accounts on top of them. Creating a login or granting someone read on a repository no longer needs shell access on the server.

quarry account still opens OLTP directly and has to: the FIRST account must exist before any server runs or any admin exists to authenticate as. Everything after that is the API, so the CLI has no privileged path.

The verifier never crosses the seam in either direction, and account.add /passwd scrub the password out of any error before it travels — an error is the one value that reaches a log, an HTTP body and a terminal at once.

Verify returns a three-valued Decision instead of a bool. Denied and Insufficient are not the same thing and the wire has separate codes for them: an authenticated client short of a capability was being told 401 with a challenge, which invites it to retry the same password forever. Now 403, and deliberately without a challenge. A harness test pinned the old behaviour and was updated with the reason. check-in: 86880118d5 user: dmestas tags: trunk

Nobody picks a filesystem path when they make a repository on a forge, and requiring one made repo.add usable only by the machine's operator. --repos-root gives the server somewhere to put them; path is now optional and the response says where it landed.

Repositories gain a description — every forge has one and quarry had nowhere to put it, so the listing could only show names and counts.

Three surfaces on one op: quarry repo new|clone|list|remove drives the HTTP API rather than the database, so the CLI has no privileged path and anything it can do a client can; /new is the same three questions a forge always asks; and an empty repository shows how to push to it instead of a bare file table, because it is waiting, not broken.

A rejected form comes back as a form with the reason on it — an error page throws the reader's input away. check-in: 87a492fe4f user: dmestas tags: trunk

Two cases quarry could not do at all. create runs zit init at the path — the 'host my project here' case. clone copies a remote in and records a mirror for it, because adopting a remote repository and then not tracking it is almost never what anyone meant.

Cloning takes the bulk lane: a large repository is minutes of network, and an admin asking for it is not a reason to run it unbounded.

Both refuse a non-empty target and undo what they made if a later step fails — the store, the OLTP row, or both. Verified: sqlite.org/docsrc adopted in 14s (5,116 check-ins, serving in 2.24ms), and a clone from an unreachable URL leaves no directory, no registration and no row. check-in: 9f78830644 user: dmestas tags: trunk

Adding a repository meant editing the server's command line and restarting, which took every other repository down with it. The registry now lives in OLTP where 0001 §8 always placed it, and repo.add / repo.remove (admin) register and tear down at runtime.

registrar owns a repository's whole lifetime — index handle, pipeline, sync backend, poll goroutine. The startup loop could not: it relied on defer ix.Close() reaching serve's return and on a poll loop that never stops, and both leak the moment a repository is removed.

Add persists before it serves, and rolls the record back if opening fails: a registration that serves without being recorded vanishes at the next restart with no trace of why. Remove stops serving and forgets, but leaves the store and index on disk — 'stop serving' and 'destroy' are different intentions and only one is reversible.

--repo stays as bootstrap and override. check-in: 2c157378a3 user: dmestas tags: trunk

Deps.Repos was a bare map, read by every op on the request path and written only at startup. Adding repositories at runtime — the point of the registry ticket — makes that a data race with no symptom until it corrupts one. api.Repos owns the lock; a *Repo is published complete or not at all, and Delete hands back the entry so the caller can close the index and stop the pipeline.

serve now refuses leftover arguments. Go's flag package stops at the first non-flag and returns the rest, so one unquoted shell variable silently dropped twelve --repo flags and quarry served the remaining eleven without a word. check-in: 4a479e6ce2 user: dmestas tags: trunk

zit frames streams a WHOLE store: 507 MB peak on sqlite, more on tcl. quarry ran one ingest goroutine per repository with nothing between them, so a cold start — or a mirror round landing artifacts in several big stores at once — ran that many censuses simultaneously and the memory added. Observed as zit spiking to gigabytes after pulling sqlite and tcl together.

--ingest-limit (default 3) puts them in a work lane. The queue is generous and ingest is never shed: dropping a round would leave an index behind its store until the next poll, trading a correctness surprise for a saving the limit already delivers. check-in: e6fd32e82e user: dmestas tags: trunk

fail() mapped only ErrNotFound, so every other kind rendered as 500 — and a 500 tells a client the request failed, not to try again. Two retryable paths lost that distinction: a single-writer lease refusal (0001 §3) and a shed from a saturated work lane.

ErrInvalid now renders 400 and ErrUnavailable 503 with Retry-After, matching what the API router has always done.

Verified with the archive endpoint, live for the first time now that zit 10a1236a7a fixes tarball -R: twenty concurrent requests give ten 200s and ten 503s with Retry-After, RSS bounded at 247 MB. check-in: e9d441a552 user: dmestas tags: trunk

Nothing in quarry limited concurrency — every zit subprocess ran in the request goroutine with the arrival rate as the only bound. work.Lane is a concurrency limit plus a queue cap that SHEDS past it: a request accepted into a queue it cannot be served from consumes the capacity that would have served someone else.

Wired to archive first, which buffers 256 MiB per request on an anonymous route. That is latent rather than live — archive 503s on zit#97 — which is why the bound belongs there now, so the endpoint is born bounded rather than acquiring a limit after someone finds it.

Footer precision: '<1ms' was true and useless once most pages went sub-millisecond, collapsing the interesting range into one label. timing.Format keeps ~3 significant figures across five orders of magnitude, so 900µs and 90µs no longer read the same. Fossil has the mirror-image bug: three decimals of seconds prints everything faster than a millisecond as 0.000s. check-in: 45bb75ade2 user: dmestas tags: trunk

zit cat costs ~147ms even for a small file, against a 3ms process floor, and every file view forked one. Under load that capped the forge at 32 req/s, degrading to 24 at twenty concurrent readers.

hash-versioned file page: 393ms -> 18ms 50 concurrent: 201 req/s, still climbing

Bounded by BYTES, not entries: values are file contents, and an entry-counted cache holding a 30MB blob is a memory leak with a polite name. Per repository, so a busy store cannot evict a quiet one's entries.

resolveVersion only expands hash PREFIXES. An earlier draft fell back to the index's branch table for names, which served tk a README from 2020: tk renamed its trunk to main, so a branch literally called trunk still exists and is six years stale, while zit resolves the word correctly. 0001 §2 makes zit the authority on names and that is not negotiable — so a symbolic version stays uncached, and the way to fix that is to make links carry the resolved hash. check-in: 0cf9a57e88 user: dmestas tags: trunk

The ticket list derived itself per request: GROUP BY over every change row (tk: 35,903), two correlated subqueries per ticket to find the newest title and status — 11,618, each with its own temp b-tree — and a HAVING that filtered after grouping, so paging saved nothing.

tk 200ms -> 1ms sqlite 1ms fossil <1ms

Written from refreshTicketDoc, which already folds exactly this state for the search doc, so the summary cannot disagree with what search sees. Backfilled at open for indexes written before the table existed.

Second instance of the same bug the timeline had, so plan_test now covers this query too. check-in: 4c973ff323 user: dmestas tags: trunk