Skip to content
zit Stores keep Fossil’s interwiki map
Login

Stores keep Fossil’s interwiki map

zit 0.7.5 can fetch, serve, import and export Fossil's interwiki map. To keep it, a store gains a new kind of record, the setting frame. A store that holds one cannot be opened by zit 0.7.4 or earlier. This note records what the map is, how it travels, how it is stored, and what that costs older readers.

What the map is

Fossil keeps the interwiki map in its config table, one row per tag: the name is interwiki:TAG and the value is a JSON object with a base URL and optional hash and wiki paths. A wiki page or check-in comment that links TAG:path resolves against that row. A mirror without the map shows those links unresolved.

Before 0.7.5, zit config pull reached the shun and user areas only, so a zit mirror of a Fossil repository could not carry the map.

How it travels

As Fossil sends it. A pull sends reqconfig /interwiki, and the server answers with one config /config card per row, carrying the row's name, mtime and value. zit serve answers the same request from its own rows to any user with Read, as Fossil does, and the /all group includes the area. The smoke suite's S31 runs both directions against stock Fossil: zit pulls the map from fossil server, and stock Fossil pulls it back from zit serve.

A pull merges by default: a row replaces the one held only when its mtime is newer. --overwrite takes every row offered. Neither removes a tag the peer no longer offers; Fossil keeps such a tag too. A row without a base, or with a tag that is not letters and digits, is skipped and counted. zit config import and merge apply a file written by fossil configuration export interwiki, and zit config export interwiki writes the same format.

How it is stored

The store is an append-only log of frames, and each frame has a kind. 0.7.5 adds kind 6, setting: one named configuration row with its mtime and value. The row for a name is the last frame written for it. A pack folds the frames back to one per name.

The frame is generic rather than interwiki-specific, so a later Fossil setting zit needs to carry is another name, not another frame kind. Today only interwiki: names are written.

The limits are fixed and checked on every path: a name of 1 to 255 bytes, a value of at most 4,096 bytes, and at most 65,536 frames in one log. A write checks them, and copies the row, before the frame is appended, so nothing that can fail follows a frame landing. Opening a store checks every setting frame's key and bounds, and the index sidecar checks its setting section's counts and lengths behind its checksum; the sidecar format moves to version 5.

What it costs older readers

A zit 0.7.4 or earlier that meets a kind-6 frame reports the store as corrupt and refuses to open it. It does not skip the frame and carry on, so it can never write past a record it does not understand.

That cost falls only on stores that take the area. A store that never pulls, imports or merges the interwiki map writes no setting frame and opens in earlier releases as before. Before pulling the map into a store, upgrade every zit that reads it, including any server that serves it.