| Comment: | repo: add and remove repositories without restarting
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. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
2c157378a3ca742644e9e14bd4db7f80 |
| User & Date: | dmestas on 2026-08-18 01:24:41.345 |
| Other Links: | manifest | tags |
|
2026-08-18
| ||
| 01:47 |
repo.add: create an empty repository or adopt one by cloning
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 | |
| 01:24 |
repo: add and remove repositories without restarting
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 | |
| 01:15 |
api: make the repo set a concurrent registry; serve rejects positionals
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 | |