Timeline

Merge bases chosen as fossil's pivot_find chooses them: the most recent common ancestor by check-in time, with the check-out's pending merges as further secondaries, in place of a bidirectional breadth-first search that picked a different base on criss-cross and skewed histories. Checked against fossil 2.28 on 114 queries and a byte-for-byte merge. check-in: 97e188b6ef user: [email protected] tags: feat/horizon-cones, trunk

The ncruces driver reads event.mtime, declared DATETIME, as a time.Time, so the pivot search failed to scan its seed under -tags test_ncruces. coalesce() drops the declared type, as the parent query's already did. check-in: 89c6ae4aa6 user: [email protected] tags: feat/horizon-cones, trunk

The merge base is now fossil's pivot, so check it against fossil(1) on every run rather than against an expectation written once. Scripted graphs, loaded into both implementations, cover a skewed criss-cross (the newest common ancestor two edges away, not the one an edge away), a criss-cross at equal times in both load orders (the higher rid wins the tie), merges of merges and a query with two secondaries, and --ignore-merges. A merge of p into a checkout of s in the skewed graph writes the same bytes as fossil's merge and differs from a merge against the breadth-first base.

TestMergeBaseFossilOracle builds six seeded random graphs of sixteen check-ins, with equal times and children older than their parents, and compares 114 merge-base questions, both directions, with and without --ignore-merges and with two secondaries, against fossil merge-base. check-in: 944b44faf6 user: [email protected] tags: feat/horizon-cones, trunk

go-libfossil picked a merge base with a bidirectional breadth-first walk, the common ancestor nearest by edge count. fossil's merge uses pivot.c's pivot_find: a queue ordered by pending DESC, mtime DESC that expands the newest pending check-in first and returns the first one with a child queued from the other side, the most recent common ancestor by event time. The two differ on criss-cross merges and skewed histories, so a merge here could diff against another base than fossil's and write other bytes.

merge.FindPivot ports pivot_find in memory: (rid, side) rows with REPLACE re-pending, ties broken as a reverse scan of aqueue_idx1 yields them (rid, then side, descending), a missing event mtime counted as 0.0, ignoreMerges following primary links only, and the walk bound of the horizon merge-base query kept as ErrBound. FindCommonAncestor and FindCommonAncestorWithin now ask it.

Call sites: - Checkout.Merge takes fossil's pid: the merged-in version primary, the checkout's version and every vmerge id=0 merge the secondaries (merge.c 1076-1083), and gains Baseline, fossil's --baseline. The name pivot nid (pivot_find(1), merge.c 1089-1096) feeds only add_renames and the rename fill-in (merge.c 1192-1257); Merge does not follow renames, so it is not ported. Update and stash use the checkout version as their pivot and pick no base. - Repo.Merge (branch merge) makes the source branch tip the primary. - The origin's horizon-mergebase answer makes the merged-in check-in primary and declines to answer from a walk that reached history it does not hold. - Deepen's local deepen point keeps a boundary target among C's ancestors as its own point, since pivot_find seeds from check-ins only.

Horizon client rule (draft-fossil-horizon-00 §5.5, agreed for the draft): a common ancestor found in part of the graph need not be the one the whole graph gives, so a merge asks the origin whenever the walk reaches a check-in the store does not hold, not only when the base it finds is not held. MergeBaseCrossing takes that from Pivot.Unheld, and MergeContext merges over the origin's base as a baseline, deepening only when the store does not hold it.

Changed expectations: the horizon merge fixtures (hzStruct's y into feat2, structuralMergeSource, TestBranchMergeRefusesBaseBelowHorizon) fork f below the horizon, merge c2 into f's line and f into c2's: fossil picks c2, not f. On that shape fossil 2.28 answers fossil merge-base y x -> pivot=52d5923b8d (c2) with f=8ac24055 also a common ancestor. The fixtures now add a check-in on f's line newer than the horizon, which fossil does pick, to keep a base below the horizon, and the crossing tests check both the held-base walk that crosses and the base below. check-in: a23c7b12a9 user: [email protected] tags: feat/horizon-cones, trunk

Appendix A step 6: the merge-base query (pragma horizon-mergebase), deepen (Repo.DeepenHorizon, repo cone deepen), merges and bisect that refuse or deepen across the horizon (ErrBelowHorizon, Checkout.MergeContext), the origin's push-time check of a branch cancellation, seed verification by deepening (Repo.VerifySeed, repo verify --seed), and symbolic names below the horizon resolving. Interoperates with zit at 9bf7ebfe0f. check-in: 19d7db48d4 user: [email protected] tags: feat/horizon-cones, trunk

Section 5.5: a tag applied to a check-in below the horizon resolves to that check-in's hash, because the control artifact is held. The resolver's sym-tag step joins event, which a check-in below the horizon has no row in, so the name was unknown and an operation on it never reached the horizon diagnostic. Both the tag: form and a plain name now fall back, in a structural store only, to the check-in below the horizon the tag names; Repo.ResolveVersion, Checkout.ResolveVersion and the CLI share the resolver, and checking it out names the horizon and the deepen. check-in: 67bb246d16 user: [email protected] tags: feat/horizon-cones, trunk

# Conflicts: # conformance/requirements/horizon.tsv check-in: 75ed88e8e9 user: [email protected] tags: feat/horizon-cones, trunk

Record Appendix A step 6 in the horizon requirements table and on the sparse page: the API and commands, what each costs, and what HZ-5.5-1 still leaves out (a symbolic name on a check-in below C, and annotate walking back past C). check-in: 078df932f4 user: [email protected] tags: feat/horizon-cones, trunk

Section 5.5 has a bisection whose good end lies below the horizon deepen to it before it begins. The path between the ends ran through a boundary phantom and the session went on as if the history were there; Next now refuses first, naming the horizon and the deepen that brings the good end, matching content.ErrBelowHorizon. The library session holds no peer, so the deepen is left to the caller. check-in: ad60dffec8 user: [email protected] tags: feat/horizon-cones, trunk

Section 5.9 asks for a verification mode so trusting the seed is a choice with a known price. sync.VerifySeed cuts the structural horizon to the content depth at the same C, which fetches every manifest below C and with them the real tag artifacts and primary-parent chains, discards the seed, and compares what the store then derives at each entry with what the seed asserted. Repo.VerifySeed and 'repo verify --seed' expose it; the store stays a content-horizon store afterward, and a failed transfer puts the structural cone and seed back. zit 9bf7ebfe0f offers no such mode. check-in: 35db744ea7 user: [email protected] tags: feat/horizon-cones, trunk

A check-in that creates a branch cancels its parent's branch tag by the name its clone derived, and under a structural horizon that name came from the seed. Section 5.7 has the origin check it against its own derivation: the handler now looks at each check-in a push stored, once crosslinked, and when the parent is on another branch here it rolls the whole push back with an error naming the stale seed and the parent's branch, spelled as zit's pushSeedCancelFault spells it. A check-in is admitted when the push or the store holds a control artifact cancelling the parent's real branch on it, and so is one whose parent this origin cannot place.

zit's check reads only the push for the correction; this one also reads the store, as the draft allows. Interop runs both ways against zit 9bf7ebfe0f. check-in: 8f89198ca1 user: [email protected] tags: feat/horizon-cones, trunk

Section 5.5 forbids merging against a base the store does not hold. In a structural store the walk can reach a boundary check-in as the base, or find none where both sides' ancestry leaves the store, and the merge then failed on a phantom with an error that never named the horizon. content.MergeBaseCrossing decides the crossing for checkout merges and branch merges alike, and the error names the horizon, the base and the deepen, matching libfossil.ErrBelowHorizon.

Checkout.MergeContext is the remedy zit's merge applies: given a peer it asks the origin for the base, deepens to reach it and merges again over the real base. 'repo merge' takes the recovery flags and contacts the remote only when a merge crosses the horizon. check-in: d8458ad960 user: [email protected] tags: feat/horizon-cones, trunk

Section 5.8 makes deepen the universal remedy of the draft: name a C' that is an ancestor of C and synchronize at it. sync.Deepen finds C' as zit's deepenPoint does, the target itself when it is C's ancestor, else a common ancestor over the P cards the store holds or asked of the origin with the merge-base query; it refuses rather than move C off its own ancestry when none can be established. Repo.DeepenHorizon and 'repo cone deepen' expose it, and the crossing diagnostic now names that command.

Moving a structural horizon through FetchCone now discards the held seed before the transfer, so the request offers none and the seed for C, applied at a later date, cannot shadow propagation from the seed for C'. A transfer that fails puts the old cone and seed back, as zit's deepen does: a store left structural without a seed derives no branch state for K. check-in: c11b3055fb user: [email protected] tags: feat/horizon-cones, trunk

A structural clone cannot compute a merge base whose ancestry lies below its horizon, so draft-fossil-horizon-00 section 6.2.4 lets it ask the origin with pragma horizon-mergebase A B. The origin answers in its pull reply, ahead of the igots where zit places it, with the base or - for no common ancestor, and only for check-ins it holds. Section 8 bounds the walk: merge.FindCommonAncestorWithin carries the held-set walk's visited-node bound and the query goes unanswered past it.

The client asks once, in the first request after the cursor, through SyncOpts.MergeBaseOf and reports the answer in the result. Interop runs both ways against zit 9bf7ebfe0f. check-in: 5612ac9771 user: [email protected] tags: feat/horizon-cones, trunk

History views render a labelled horizon boundary as the horizon (draft-fossil-horizon-00 §5.4): Repo.Ancestry ends there without an error, Repo.Timeline and LogEntry report it in HorizonParents, and repo timeline prints it as (horizon). An unlabelled absent parent renders as before. check-in: d0c44dbc25 user: [email protected] tags: feat/horizon-cones, trunk

A parent the origin labelled below a structural horizon is the horizon itself (draft-fossil-horizon-00 5.4), but the history views showed it as a bare parent hash, and the ancestry walk tried to read an event for it.

LogEntry and TimelineEntry gain HorizonParents, the subset of Parents that carries a boundary label; Ancestry ends at such a parent without an error; repo timeline prints it as "parent: <hash> (horizon)". An absent parent that is not labelled is transit and renders as before. check-in: ee3ccc7c67 user: [email protected] tags: feat/horizon-cones, trunk

The structural horizon (draft-fossil-horizon-00 Appendix A step 5): a store at structural depth elides manifests and nodes below the horizon and keeps boundary labels; the client sends horizon-structural and horizon-seed and holds the seed it is sent; the origin restricts manifests to the held set, labels the boundary, mints and sends the seed, and serves structural only when the seed is current. Interoperates with zit at 9bf7ebfe0f in both directions. check-in: 78ed31bf91 user: [email protected] tags: feat/horizon-cones, trunk

A push alone carries no horizon pragma, so its reply says nothing about how the horizon is served, and a structural store pushing to its origin fell back to the content horizon. The first reply decides only when the request pulled. Preconditions of the structural serving and receiving paths are asserted. check-in: 1abe24cd2b user: [email protected] tags: feat/horizon-cones, trunk

A structural store elides a phantom nothing it holds names, and an igot makes exactly such a phantom, so a structural store serving a push never asked for the pushed check-in and a pull relied on the session alone to want it. A name the peer announced in the exchange is now asked for when nothing held names it, on both sides; a labelled boundary or a tag's below-horizon target stays elided. check-in: 26aff82ccc user: [email protected] tags: feat/horizon-cones, trunk

Composed with path members, a structural horizon keeps K's trees, but an origin may withhold their nodes outside the cone, as zit's does since 2b635ea5ce. Those nodes classified transit, so a clone from zit stalled waiting on them. A node the path members exclude is now elided under a structural horizon, as a path cone elides it; zit interop under cone src proves it both ways. check-in: 74ac2ea4c1 user: [email protected] tags: feat/horizon-cones, trunk

Cases for the ordinary commit from a structural store (§5.7), the leaf verdict over one (§3.1), verification and crossing (§5.4, §5.5), and the requirements table updated to what the structural horizon now covers; what remains, with the Appendix A step that covers it, stays in the notes. check-in: d9e74912e8 user: [email protected] tags: feat/horizon-cones, trunk

Horizon gains Structural, whose zero value is the content horizon, so a Horizon built before it means what it meant; clone and sync results say how many replies served the structural level and whether the store fell back. repo clone and repo cone store take --structural with --horizon.

A structural store's history ends at its horizon, which the commands now say rather than leave bare phantoms (draft-fossil-horizon-00 §5.4, §5.5): repo info names the horizon and the check-ins below it, repo verify counts them apart from damage, and checkout, diff and annotate of a check-in below C fail naming the horizon and the deepen that reaches it. check-in: c61a17d9ab user: [email protected] tags: feat/horizon-cones, trunk

zit clones and pulls at a structural horizon from go-libfossil's origin, and go-libfossil clones and pulls at one from zit serve. Each origin withholds the manifests below the horizon, labels the boundary and sends the seed; each client stays structural and derives the branch, leaf and tag state of the held set as a dense clone of the same origin does, including after a tag below the horizon moves the state at an entry and re-seeds it. zit holds the very seed go-libfossil mints. check-in: b76863738f user: [email protected] tags: feat/horizon-cones, trunk

The origin now answers pragma horizon-structural (draft-fossil-horizon-00 §6.1, §6.2): it keeps only the manifests and nodes the held set reaches, labels every boundary hash at the head of each reply (§6.2.2), mints the seed for C and sends it, pragma ahead of its file card, when the client offers another name (§6.2.3), and advertises the structural level only then; a request it cannot place or seed is served as content. It refuses a seed offered to it and withholds a gimme'd manifest below the horizon.

A structural store's requests carry horizon-structural and the seed it holds. It routes the announced card to seed.Hold after checking its name and shape, never storing or announcing it, records the labels, and applies the seed after each reply and after the closing link. A first reply that does not serve structural with a seed, or a seed failing provenance, makes it a content-horizon store for good, reported in the result, and the manifests below the horizon are fetched (§5.1, §5.2.4, §6.3). check-in: dc33bca3a6 user: [email protected] tags: feat/horizon-cones, trunk

A sparse store defers a check-in whose parent it lacks, so that mlinks wait on a complete parent tree. Under a structural horizon (draft -fossil-horizon-00 §5.1) the parents below the horizon never arrive, so C and every entry of K stayed unlinked. An absent source no longer defers there; the check-in links against the phantom as a dense store links it. check-in: 79ec72f88e user: [email protected] tags: feat/horizon-cones, trunk

The seed's rows name their target as their source, and the crosslink treats a blob that sources a tagxref row as already linked. A sync stores an entry before it links it, so a seed applied in between left the entry unlinked for good: no event, no plink, no leaf. Apply now skips a target the store has not linked; the sync layer applies again after the round that links it. check-in: c7c0c130bd user: [email protected] tags: feat/horizon-cones, trunk

A structural-horizon clone (draft-fossil-horizon-00 §5.1) keeps only the manifests and nodes its held set reaches, so its phantoms need classes the content horizon never had: a parent the origin labelled below the horizon is elided, an unlabelled one stays transit because it may only be late (§5.3), and a phantom only a tag or cherry-pick names is a manifest below the horizon nothing in K reaches. SetStoreCone stops refusing the depth, and keeps the boundary labels beside the store cone, dropping them when the horizon moves since they name what lies below one C. check-in: 31b140507a user: [email protected] tags: feat/horizon-cones, trunk

A docs page for sparse cones and horizons: concepts, the library API, the CLI, interop with zit and fossil 2.28, and the limits as they stand. check-in: 441604df52 user: [email protected] tags: feat/horizon-cones, trunk

The page described the leaves rule as each childless check-in's ancestry back to its meeting point with C, the rule before zit#265. The rule at the pinned draft holds every descendant of each meeting point, which is why it holds nearly all of fossil-scm.org's history: old unmerged branches fork near the root. check-in: 097153487d user: [email protected] tags: feat/horizon-cones, trunk

The structural horizon's seed (draft-fossil-horizon-00 §5.2): an origin mints a control artifact carrying the tags in force at every entry of the held set, a clone holds it outside the artifact store where no sync, clone or rebuild can reach it, and the derivation applies it so every check-in in K derives as it does densely. Byte-identical to zit's seed when the latest summarized event is on a whole second. Conflicts in the horizon suite and table kept both sides; the seed's zit test now probes for a horizon-capable zit like the other horizon interop tests. check-in: 12dcbdeed6 user: [email protected] tags: feat/horizon-cones, trunk

The cursor slice keeps a client's horizon cursor per origin, named by the internal SyncOpts.Origin, but the public Repo.Sync never set it, so a library or CLI sync kept no cursor and every request announced in full. The HTTP transport now names its peer by its URL with any password removed, as last-sync-url keeps it, and Sync passes that through. Other transports name no origin and keep announcing in full, which §6.2.6 allows. The test pulls with a credential-bearing URL and finds the cursor under the password-free one, and no config row holding the password. check-in: 331b540f1c user: [email protected] tags: feat/horizon-cones, trunk

The horizon cursor (draft-fossil-horizon-00 §6.2.6): an origin that classified a request answers pragma horizon-cursor with its position, a converged client records it per origin and cone and sends it back, and neither side announces again what the other already has. Interoperates with zit both ways. check-in: f704c6d58b user: [email protected] tags: feat/horizon-cones, trunk

A horizon pull announced the client's whole holding with igot on every request, and the origin answered with its whole kept inventory: one card per artifact, both ways, on every pull. draft-fossil-horizon-00 §6.2.6 replaces both with a position.

The origin values pragma horizon-cursor right after horizon-served in every reply to a horizon pull, as zit places it. Its position is rid order (the clone SEQNO sense), stopped short of the lowest phantom: a filled phantom keeps its old rid, so a cursor covering it would hide the arrival. Receiving a cursor, any reply that pulls announces nothing at or below it. A filled phantom that a check-in from an earlier receipt already named as parent is recorded as the reclassification position; a cursor below it is answered as if absent. A cursor beyond the origin's own position is ignored.

The client keeps, per origin and cone, the last reply's cursor and the rid count the origin holds through, sends the cursor on every request, announces nothing on a pull-only request and only what it appended on one that sends. Sessions name their origin with SyncOpts.Origin; without it nothing is kept and every request announces in full. check-in: b61bd3475c user: [email protected] tags: feat/horizon-cones, trunk

TestZitHorizonInterop took whatever zit was on PATH. A zit release from trunk reports the same version as the horizon-rfc build but has no --horizon flag, so the test failed in zit's argument parser. The new zitHorizonBinary probes the binary for horizon support, as zitBinary already probes for send-submanifests, and skips it, or fails the run under REQUIRE_ZIT_BIN=1, with the reason. check-in: 27b85364f2 user: [email protected] tags: feat/horizon-cones, trunk

The public horizon API in the shape approved: a horizon is part of Cone (NewHorizonCone, Cone.Horizon, Cone.WithHorizon), store cones carry it through SetStoreCone and SetStoreConeContext and the new CloneOpts.StoreCone, checkout cones refuse it with ErrHorizonCheckout, and the CLI takes --horizon and --leaves on repo clone and repo cone store and --no-horizon on repo cone store. check-in: 964b91f682 user: [email protected] tags: feat/horizon-cones, trunk

A store cone could carry a horizon only through internal/cone, so library users and the CLI had no way to clone into or edit a content-horizon store. Add Horizon, HorizonRule, NewHorizonCone, Cone.Horizon and Cone.WithHorizon over the internal cone (always the content cut), carry it through SetStoreCone/SetStoreConeContext (deepening fetches what the older check-in keeps) and CloneOpts.StoreCone, and add --horizon, --leaves, --no-horizon and --cone to repo clone and repo cone store.

A horizon is a property of the store, not of a checkout (draft-fossil-horizon-00 3.2), so checkout cones carrying one are refused with ErrHorizonCheckout, and widening the store from a checkout cone keeps the store's horizon. check-in: e5904fc85b user: [email protected] tags: feat/horizon-cones, trunk

Appendix A step 3 without the cursor: the client sends pragma horizon, the origin computes the held set over its dense graph, sends only the blobs above the horizon, inflates crossing deltas, sends no cluster, answers horizon-served content and refuses what it cannot cover (§6.4). Against a horizon-ignorant origin the client requests what its clusters name, as transit (§4.5 after zit#266). Interoperates with zit both ways. check-in: 84be5ad824 user: [email protected] tags: feat/horizon-cones, trunk

The Appendix A step 4 measurement: an opt-in corpus test reporting what a structural horizon saves over a content horizon at several depths. check-in: 5430186930 user: [email protected] tags: feat/horizon-cones, trunk

zit#266 reported that a horizon clone pulling from stock Fossil never learns a check-in Fossil announced only inside a cluster: xfer.c clusters 100 or more unclustered artifacts and then announces only the cluster. §4.5 at 9bf7ebfe0f binds the cluster prohibition to an origin whose replies carry horizon-served, and has the clone request a horizon-ignorant origin's cluster members as transit and classify what arrives. HZ-4.5-1 is restated; implementing it waits for horizon-served, which the horizon pragmas bring. The sync draft on that branch differs from the trunk copy pinned here only by §9's editorial list of extension pragma names. check-in: d5926b325c user: [email protected] tags: feat/horizon-cones, trunk

A content-horizon store against any peer: below-horizon blobs it is sent are recorded as elided rather than stored, it holds and requests no cluster, and a below-horizon blob an operation needs is fetched on demand. check-in: 27b8439777 user: [email protected] tags: feat/horizon-cones, trunk

No peer speaks the horizon pragmas yet, so a content-horizon store receives whatever a dense peer sends (draft-fossil-horizon-00 §6.3). The received-content filter now applies the horizon's classification, read from internal/content rather than re-derived: blobs below the horizon become elided phantoms and are counted in the result's Elided. Blobs no held manifest names yet stay as unreferenced holdings, and retained delta bases stay transit (§4.2).

A horizon store also acts on no cluster (§4.5). Crosslinking a cluster applies its tag but makes no member phantoms. The filter drops the cluster's content, and classification elides any phantom that carries the cluster tag. The client stops sending req-clusters. Path-cone-only stores keep today's cluster behaviour.

Conformance cases run against go-libfossil's handler and fossil(1): clone and pull, deepen, demand fetch through UpdateContext, transit deltas, and cluster rules. check-in: f1f4240f40 user: [email protected] tags: feat/horizon-cones, trunk

Sparse-store classification sized to what it proves rather than to the store: file content is never read, completely linked check-ins answer from the crosslink tables, and a content horizon reads only its held set's trees. A path-cone store of fossil-scm.org classifies in about 2 s at a 65 MiB peak, where v0.14.0 failed with a byte-budget error. check-in: cd1b25e114 user: [email protected] tags: feat/horizon-cones, trunk

Sparse classification read, inflated and delta-expanded every held blob, file content included, under a whole-store byte budget. On a clone of the Fossil SCM repository (67,894 blobs, 8.4 GB expanded) LoadAbsences failed at once with "byte budget exceeded", so no path-cone or content-horizon store of a real repository could classify its phantoms, and pull, verify and compaction failed with it.

Reference facts now come from the tables wherever they provably stand in for raw cards. A blob the crosslinker recorded as no artifact and mlink names as a file version is never read. A completely linked check-in (event row, no orphan row, a primary parent edge) whose primary parent and baseline trees are themselves reproduced contributes its mlink rows as F cards and its plink, cherrypick and tagxref rows as references; by induction over the primary chain those rows give the same (name, file) pairs as its raw cards. Everything else is still read raw: unlinked and orphaned check-ins, roots, check-ins whose parent never arrived, other artifacts, and every check-in once the store has seen a sub-manifest, since trees are not crosslinked. Budgets are charged per round for the selected blobs and their delta ancestors only, and a base's bytes are released once its last delta is applied.

A content horizon now reads only its held set's manifests and the baselines and nodes they reach, on demand, with one visited set and a byte budget scaled to the held set.

On the Fossil SCM clone, cone {src} classifies in about 2 s at a 65 MiB peak heap, reading 8,655 of 67,894 blobs; the inside/outside sets equal the all-raw result, and Outside/Required agree on every artifact. check-in: b28c06506b user: [email protected] tags: feat/horizon-cones, trunk

The content horizon's store classification: a blob is elided when no check-in in the held set names it through its full tree, a kept blob is in both keep sets under a path cone, structure is never elided under a horizon, and a horizon the store cannot place elides nothing, as zit does. check-in: bc54a61b2c user: [email protected] tags: feat/horizon-cones, trunk

# Conflicts: # conformance/horizon_test.go # conformance/requirements/horizon.tsv check-in: 80c8df6a74 user: [email protected] tags: feat/horizon-cones, trunk

A store cone may now carry a content horizon (draft-fossil-horizon-00 §3.2, §4.1-§4.3). Classification computes the held set K from the store's own check-in graph and walks K's full trees -- F cards directly, through B baselines and through S sub-manifest nodes, with one visited set over structural names -- because mlink records a file version only where it changed, and a blob introduced below C and unchanged through C is named by C's tree alone. Nothing about K is stored: every classification recomputes it, so moving C or losing the cone is a reload, never a migration.

Blobs no K check-in names are elided; with path members as well a blob is kept only when it is in both keep sets. Under a horizon nothing structural is elided, by the horizon or by path members, and delta bases of held artifacts and shunned names keep their classes. A C the store does not hold elides nothing, as zit's classification does: eliding everything would leave the pull that brings a deepened C nothing to ask for. A structural horizon is refused by SetStoreCone until it is implemented.

internal/content now imports internal/horizon, so the held-set tests, which commit through internal/manifest, move to an external test package to avoid an import cycle. check-in: 2ea6479ba9 user: [email protected] tags: feat/horizon-cones, trunk

zit's author called horizon-rfc bbd1435674 ready to implement against, and zit#265 settled the leaves rule there against fossil's leaf: a childless check-in is one no P card names, open or closed, and K under the leaves rule is C's descendants plus every descendant of each check-in where a childless check-in's ancestry meets C's. Both rules now yield a set closed under descendants, so leaves and branch tips derive exactly.

HeldSet follows zit's computation at that check-in (src/sparse.zig, ClassifyState.extend): meeting points are the members of C's ancestry a childless check-in's parent walk reaches without passing one, and a childless check-in is skipped only when it descends from C. The tests that encoded the old rule are restated: a merged-but-open branch tip adds nothing, a closed branch's tip does, the fork's descendants on C's side are held, and an unrelated root adds nothing.

The draft copy, the README pin and the table follow: HZ-3.1-1, HZ-5.2-1 (the seed applies to every entry of K) and HZ-6.2-11 (announce only in reply to a request that pulls) are restated, and HZ-3.1-4 (closure under descendants) is new, with a case checking that no child of a held check-in falls outside K under either rule. check-in: a68f89e414 user: [email protected] tags: feat/horizon-cones, trunk

Both slices defined the descendants/leaves rule: cone.HorizonRule for the serialized member and horizon.Rule for the walk. One concept gets one type; the walk now takes the value the cone carries. check-in: 6d8ccec5da user: [email protected] tags: feat/horizon-cones, trunk

The held set K of draft-fossil-horizon-00 §3.1 under both rules, bounded and computed from the check-in graph the repository holds. Conflicts in the horizon suite and table resolved by keeping both slices' cases and rows. check-in: 7a5ae7cee7 user: [email protected] tags: feat/horizon-cones, trunk

draft-fossil-horizon-00 Section 3.1 defines K as a function of C, the rule and the check-in graph, recomputed by whoever needs it and stored by no one. internal/horizon.HeldSet computes it from the plink and leaf tables: one bounded plink load, then iterative breadth-first walks.

Merge parents are followed both ways, as zit's walk does (src/sparse.zig, ClassifyState.extend and walkParents). Under the leaves rule each open leaf's ancestry is held up to where it meets C's ancestry, inclusive, so every equally near common ancestor the walk reaches is held. "Open leaf" is fossil's leaf table minus active closed tags rather than zit's "no held child", which keeps a below-C branch merged into a descendant held back to its fork, so any two open leaves keep their merge base in K. C that is not a held check-in is ErrNotHeld; phantom parents are never entered.

Section 8 requires the walk to carry visited-node bounds: the load and every walk share the 1<<20 bound of the other graph walks and fail with ErrBound, and cancellation is honoured. The conformance suite gains cases for HZ-3.1-1 and HZ-3.1-3, both PARTIAL until the horizon member and the content horizon exist. check-in: 75ded1b0e0 user: [email protected] tags: feat/horizon-cones, trunk

The horizon member of a cone and its version-3 serialization, byte-identical to zit's (draft-fossil-horizon-00 §3.3). check-in: 6da46813f9 user: [email protected] tags: feat/horizon-cones, trunk

A horizon names one check-in by full hash, a held-set rule and a depth. Version 3 carries it between the count and the flagged members, a distinct version so a reader predating horizons refuses the cone instead of reading the lead-in as path members. Forms without a horizon are unchanged, so their digests hold. A horizon-only cone has no path members and is path-dense. Parse re-serializes and compares, so an upper-case hash or any other non-canonical input is refused.

HZ-3.3-1 and HZ-3.3-2 are now covered. check-in: 5f637a3b62 user: [email protected] tags: feat/horizon-cones, trunk

Moves the horizon copy from 86d4b67372 to e6ee276c89, the check-in the sparse-cone copy is already pinned at. Every change between the two is in §6: §6.1 lets any request carry pragma horizon-cursor, §6.2 adds the SHOULDs to keep the classification and the structural graph per store prefix, and §6.2.6 defines the cursor. Five new rows read them into the table (HZ-6.2-9 to HZ-6.2-13) and HZ-6.1-1 names the cursor; the table is now 50 requirements, none implemented. check-in: be103fe35a user: [email protected] tags: feat/horizon-cones, trunk

chore(release): v0.14.0 changelog leaf check-in: 6d5357235a user: [email protected] tags: main, trunk, v0.14.0

feat: sub-manifest trees and sparse cones (draft-fossil-submanifests-00, draft-fossil-sparse-cone-00) check-in: 7244496a09 user: [email protected] tags: main, trunk

StartServer kills the server's process group and reaps the leader, but fossil server forks a child per connection, and SIGKILL reaches that child asynchronously. On a loaded machine the child could still finish a write after Wait returned, and t.TempDir's RemoveAll failed with "directory not empty" (TestCloneFromRealFossilUncompressedReply, load average ~20). This is the race #352 narrowed; cleanup now also waits, for at most five seconds, until the group has no member left. leaf check-in: f1b6155c8f user: [email protected] tags: feat/submanifest-reader, main, trunk

Five fixes the three-tool round trip and the fossil-scm.org comparison surfaced: an uncovered clone is refused with the push card first, repo status reports the checkout's changes, repo clone remembers last-sync-url, repo verify reports damage, transit phantoms and elision, and adding a directory adds the files beneath it. check-in: b3c5ad7bca user: [email protected] tags: feat/submanifest-reader, main, trunk

TestScenarioClusterConvergence calls content.GenerateClusters once the simulation is over, to check the API on a repository of 500 blobs. Buggify was still armed, so at hostile seeds 11 and 23 a write-path site corrupted a cluster artifact, blob.Store's round-trip check refused it, and the test failed on the refusal. That refusal is the safeguard working. The call now runs with injection suspended, as the invariant checks and fixtures do. check-in: 0be3dddeae user: [email protected] tags: feat/submanifest-reader, main, trunk

Repo.Verify expanded every non-phantom blob on its own with content.Verify. Each expansion re-applies the blob's whole delta chain, so the cost grows with the square of chain length. On a clone of fossil-scm.org's repository (67,894 blobs, chains averaging 532 deltas and reaching 2,546) repo verify took 49 minutes of CPU on both main and this branch, against six and a half minutes for fossil test-integrity.

content.ExpandAll already walks the delta forest from its roots and applies each delta once, binding every result to its name; internal/verify uses it. Verify now goes through it, with the same blob selection (size >= 0), and names the failing rid in its error. The same clone verifies in 19 seconds. check-in: 6f269e32a9 user: [email protected] tags: feat/submanifest-reader, main, trunk

The simulator arms Buggify when it is built, and the scenarios seed their fixtures after that. Two setups dropped blob.Store's error, so a store the injection failed left an empty UUID, and TestScenarioAuthRestrictedCaps panicked in blob.Exists's precondition when it asserted on it. The seed sweep hit this at adversarial seeds 5 and 8.

seedTx suspends injection for the fixture transaction and fails the test if it does not commit. Every unchecked setup transaction in the package now goes through it. check-in: c796b51895 user: [email protected] tags: feat/submanifest-reader, main, trunk

Manage stored a named directory, "." included, as a tracked file, and the next commit failed reading it. A named directory now expands through the checkout's bounded, cone-aware walk to the files beneath it, skipping paths with a dot component as fossil's add does without --dotfiles; a file named explicitly is kept as given. An uncovered path is refused as such before its absence on disk is reported. check-in: 9e28f473cc user: [email protected] tags: feat/submanifest-reader, main, trunk

repo verify hashed the held blobs and printed a fixed line. It now runs the full verifier the library uses for rebuild, prints each issue, and reports transit phantoms apart from elided artifacts, as sparse-cone 5.2 requires of a verification operation: a store complete within its cone verifies healthy and shows its elided count. check-in: 168062ca33 user: [email protected] tags: feat/submanifest-reader, main, trunk

go-libfossil read last-sync-url as the default peer for repo cone store, widening and required-content recovery, but nothing wrote it, so only a repository fossil had cloned had one. repo clone now stores its source as fossil clone does, with any user name and without the password. check-in: caf59be3b2 user: [email protected] tags: feat/submanifest-reader, main, trunk

Run from inside a checkout with the default --dir ".", repo status reported every tracked file MISSING: filepath.WalkDir's root entry is named ".", and the hidden-directory rule skipped it, and with it the whole tree. The command also compared the disk with tip rather than the checked-out version, so a checkout of an older version read as edited.

The command now opens the checkout and prints Checkout.Status, which classifies changes against the checkout's version as fossil's changes command does, cone included, with fossil's labels. Untracked files are no longer listed; fossil status leaves those to fossil extras. check-in: ea23bc8a41 user: [email protected] tags: feat/submanifest-reader, main, trunk

A sparse store that does not cover a clone (sparse-cone 5.3) answered with the error card alone. fossil 2.28's clone client reads a first round without a push card as an empty, finished clone: it exited 0 and left a repository with no project code and no artifacts.

The refusal now goes through refuseClone, the path page_xfer's refusal of an unauthorized clone already took: the reply is reset, the push card naming the repository goes ahead of the error, and no later card is read. fossil then aborts with the refusal and leaves no file. go-libfossil's client, given the codes, re-asks once and stops at the second refusal, as fossil's does. The origin-refusal case now runs fossil clone against the refusing store. check-in: fb6c1d71a1 user: [email protected] tags: feat/submanifest-reader, main, trunk

The safety checks ran while simio's Buggify was armed, so the read-path sites in blob decompression and content expansion truncated or flipped the bytes each check expanded. Every seed at the adversarial and hostile levels then reported a blob-integrity violation that was never persisted; CI runs the normal level only, so nothing caught it.

simio.SuspendBuggify switches injection off and returns a resume that restores the previous state with its random stream intact, so a check mid-run does not change the run's later choices. Every exported check in dst/invariants.go suspends for its duration. A guard test arms Buggify over a clean repository and fails without the change.

Also records in the CHANGELOG that ExtractOpts and RepoOpenCmd are no longer comparable. check-in: dfdf391349 user: [email protected] tags: feat/submanifest-reader, main, trunk

zit #262 settled the pull-inventory cost in the draft: a dense inventory can cost a requester the out-of-cone blobs of check-ins announced in the same inventory, since those names stay transit phantoms until a held manifest classifies them, and the filtering of 6.3 elides them on arrival. That is what the requester here does, so SC-6.2-4 closes. Its case now checks both halves: a blob announced with its check-in is never held, and one announced after it is never requested. check-in: 07d79d60eb user: [email protected] tags: feat/submanifest-reader, main, trunk

The draft now settles zit #257 to #260, so the four rows that waited on it close against code:

- Compaction and local filtering keep every manifest and sub-manifest node, interiors included (5.4, 6.3). RetainProvenance previously let an outside interior whose children were all held leaves go; the draft now requires it held, since it is the range proof that reaches the leaf. - A server answering a cone request acknowledges the reply with pragma cone-served in its leading pragma run (6.3). This server applies a request's whole cone or refuses it, and a refusal resets the reply, so the pragma is never sent for a refused or dense reply. SyncResult and CloneResult report ConeServed beside Elided, now public too. - An empty cone is refused (3.2); a new row and case pin it, locally and over the wire. - The per-round bound covers the tree walk only (6.2). A new row tests that a requester does not act on a dense inventory. It stays partial: an out-of-cone blob announced in the same reply as its check-in cannot be classified yet and is fetched, then filtered; zit #262 asks the draft to account for that cost. check-in: b5a64230b3 user: [email protected] tags: feat/submanifest-reader, main, trunk

A sparse clone sends the spine, in-cone nodes and in-cone blobs of draft 6.2; a held blob no F card names is none of these, so it is not sent, though zit's keep set holds it. check-in: 4529a3f71c user: [email protected] tags: feat/submanifest-reader, main, trunk

The per-round walk serves a cone clone, and nothing but tests reached the prepared index or the service that built it, so both go with their successor index. The whole-store reference loader stays for the pull inventory, compaction, verification and crosslink, and keeps its budget tests. The shun and private gates the prepared tests covered are now checked against the walk. check-in: ef6efa9f1e user: [email protected] tags: feat/submanifest-reader, main, trunk

A sparse walk now sends one clone-cap cookie per round naming the row the next round starts at, with a part-walked check-in's progress. A request that returns to that check-in without echoing its progress comes from a client that drops it; the round steps past the row instead of resending the same batch forever, and the next pull fetches what the walk owed by name. A gimme in a cone request is answered densely, since the requester names it (6.4). The SC-6.2-1 note records the pull inventory's whole-store read, which matches zit's. check-in: 6766dd6cba user: [email protected] tags: feat/submanifest-reader, main, trunk

Revert wrote a restored file with vfile's bits, which a pending merge may have changed, and left them in vfile. Fossil's revert writes the file with the reverted-to version's permission and records it in vfile.isexe and islink, so reverting a file whose only change is a merged executable bit takes the bit back off. versionPaths now carries each file's permission. check-in: da5d6546bb user: [email protected] tags: feat/submanifest-reader, main, trunk

Apply now does what fossil's stash_apply does when a stashed file changed since the stash: it merges the stashed change (pivot: the stash baseline) onto the file on disk with merge_3way, writing fossil's conflict markers and NAME-baseline/-original/-merge on conflict, an empty file for binary content, and reporting each conflict. Previously the stashed bytes were restored verbatim, losing the current change.

Save reverts a file with a pending merge to the checked-out version's executable and symlink bits, and records them in vfile, as fossil's revert does; the stash keeps the merged bits and the pop restores them. checkout.VersionPaths becomes VersionPerms to supply those bits.

The sparse stash-record-only conformance case now expects fossil's result: a file the merge took unchanged keeps the checked-out content after a stash round trip. check-in: 04e3ea8301 user: [email protected] tags: feat/submanifest-reader, main, trunk

Committing deltifies each manifest against its successor, so the first check-in's chain puts later manifests on the wire before their rows. A sparse round skipped those rows as already sent and never walked them, leaving their in-cone files to a later pull. The row is now walked without being sent again. Walk-only clones in the new cases hold no transit phantoms. check-in: 6791486470 user: [email protected] tags: feat/submanifest-reader, main, trunk

A clone round now reads and walks only its batch. What remains of the MUST is a cone-scoped pull, which still classifies the whole held store to filter its igot inventory and gimme answers. The walk also carries its request context explicitly. check-in: cbc0f9a21e user: [email protected] tags: feat/submanifest-reader, main, trunk

A cone-scoped clone no longer classifies the whole held store before its first round. Each round reads only the rows it reaches: structural artifacts go out at their row, and a check-in's row walks its tree, descending only nodes whose key range meets the cone and that its primary parent's tree does not carry over the same range, then sends the in-cone nodes and blobs that walk reaches. Content and sub-manifest rows wait for those walks and are charged as excluded rows are, so a round's work tracks its batch. A check-in whose walk outgrows a round resumes in the next one from progress kept in the clone-cap cookie. Delta bases the round did not reach are served in full form. The walk keeps the depth and visited-node bounds per request.

A round spent wholly inside an excluded run sends nothing yet advances its cursor; a coned clone now continues on that progress instead of reporting that the server stopped sending.

HandleEnd reports the artifacts a cone request classified. check-in: 2909f2a676 user: [email protected] tags: feat/submanifest-reader, main, trunk

Save no longer refuses while a merge is pending. As fossil's stash save, it stashes each changed file against the content last written for it (mrid) and reverts only the stashed files, so vmerge is kept and the next commit records the merge parent. A file the merge added is not in the checked-out version, so its revert deletes it.

Apply now fails before writing anything when a stashed modified file is missing from disk, as fossil's pop fails with "no such file" and rolls back; this is what a merge-added file meets after the save.

In a sparse checkout the record-only merge outside the cone is left pending and unmaterialized, and the in-cone files round-trip. check-in: c314e928f8 user: [email protected] tags: feat/submanifest-reader, main, trunk