Skip to content
zit Artifact [9c1ddfdf52]
Login

Artifact [9c1ddfdf52]

Artifact 9c1ddfdf52f29ce5b42f8a7047d50448aee2abc0332382e9356de4afa81fe828:


# zit 0.7.2

zit 0.7.2 closes the limit 0.7.1 named: a store no longer keeps a seed
that a peer sends it outside a seed announcement, so it can never serve
one on. The horizon draft states the rule. `zit info` also shows a
horizon clone's horizon and the origin's history URL.

This release is from trunk. Stores are unchanged from 0.7.1.

## A received seed is never stored

A seed is private to the clone that holds it, and an origin sends one
only under a `horizon-seed` announcement, which a clone keeps outside
its artifact store. 0.7.1 refused a pushed seed, but an artifact of the
same shape arriving on a clone, pull or sync was stored as an ordinary
control artifact. zit never derived tags from it, but it could serve it
to other peers.

Now every receive path drops an artifact that carries the store's seed
label (`zit-seed`) or a `horizon-seed` binding card. The test is made on
the artifact's verified content when it is written, whether it arrived
in full or as a delta completed in a later round. A dropped artifact is
not counted among those received. An artifact sent as a delta against a
dropped one is stored in full. A control artifact under another label
and with no binding card is kept as before.

A zit origin writes pushed artifacts through the same path. It already
refuses a pushed seed before writing anything, and it drops a pushed
delta whose base it lacks, so a seed completed by a later push never
reaches it. The check stands behind both.

zit remembers what it dropped, in `.zit-cache/dropped-seeds`, and
never asks a peer for one of those again. The record is local and is
never synchronized; deleting it costs one re-fetch and a second drop.

## `zit info` names the horizon

In a horizon clone, `zit info` now shows the horizon, and the history
URL when the origin gave one with `zit serve --horizon-url`:

```
horizon:      <full hash of C> (descendants, structural)
horizon-url:  https://forge.example/api/v1/r/x/history
```

The clone records the URL from the last reply that said which horizon
level it served, so it follows the origin if the URL changes.

## The horizon draft

`docs/rfcs/draft-fossil-horizon-00.txt` states the receive rule in
Section 5.2.3. It also states that a store which keeps a delta whose
base it lacks must not announce or serve that delta while it cannot be
expanded. Appendix C records the change.

## Test harness

The Fossil round-trip script stopped the subshell that started `zit
serve`, not the server, so each run left a server listening. It now
stops the server. Smoke scenarios that start a server on a fresh
loopback port try another port when the first is taken before the
server binds.

## Compatibility

Stores are unchanged from 0.7.1, in both directions. A store written by
an earlier release may hold a seed-shaped artifact. zit still skips it
when deriving, and a peer running 0.7.2 drops it on receipt.

On the wire nothing changes.

## Qualification

The release manifest records native qualification against the exact tagged
source archive on macOS ARM64, Linux x86-64 and Linux ARM64, using the pinned
Zig 0.17.0 toolchain. Publication is gated on unit and end-to-end tests, Git
differentials, deterministic simulation, seeded fuzzing, and Fossil
interoperability checks on every distributed target.

For the basis of the conformance claim, see
[the 0.1.0 release notes](RELEASE-NOTES-0.1.0.md).