Skip to content
go-libfossil Artifact [efa71c325e]
Login

Artifact [efa71c325e]

Check-ins Using Download Hex

Artifact efa71c325efc278360b0598d05ca196b3f53b46d3460c5abff4025808be53baf:

# Requirements of draft-fossil-horizon-00, written from the draft text.
# Implemented so far: the horizon member of the cone (§3.3); the §3.1 held
# set (internal/horizon); and the content horizon over a store's own
# manifests (§3.2, §4.1-§4.3: internal/content's classification), whose
# rows have cases and no scope note but HZ-4.1-1's cluster clause. Every
# other row carries a scope note naming the Appendix A step that will
# cover it.
# Skipped, with reasons: 1.2 and 1.3 (design statements that the normative
# sections restate), 3.4 except its two SHOULDs, 5.9 except its SHOULD, 7
# and Appendix B (informative), 9 (IANA).
# Format: <id>\t<section>\t<requirement>[\t<scope note>]
# draft	draft-fossil-horizon-00.txt	2e1002e1137ba99f8529bbb05882c0522a9a55d5a4d3a925cab0893fc12b1bed
HZ-1.1-1	1.1	An implementation may provide the content horizon alone; the structural horizon presupposes the content horizon.
HZ-3.1-1	3.1	A horizon names one check-in C by its full artifact hash and one of two held-set rules: descendants (the default), C and every descendant of C; or leaves, those plus, for every childless check-in L not descended from C, every descendant of each nearest common ancestor of L and C, that ancestor included.
HZ-3.1-2	3.1	A client that expects to merge across live branches offline should choose the leaves rule knowingly.	not yet implemented: the horizon member, Appendix A step 2
HZ-3.1-3	3.1	The held set is a function of C, the rule and the check-in graph, recomputed by clone and origin from what each holds, and stored by no party.
HZ-3.1-4	3.1	Both rules are stated over P cards alone and yield a set closed under descendants: every child of a check-in in K is in K. Childless means no check-in names it in a P card, open or closed, not the same-branch leaf of repo-state.	covered for the held set (internal/horizon); derived leaves and branch tips over a horizon store await the structural horizon, Appendix A step 5
HZ-3.2-1	3.2	A horizon is store-adjacent local state: not an artifact, not synchronized, affecting no artifact's bytes or name; its loss reclassifies every elided artifact as a transit phantom and the store heals toward dense.
HZ-3.2-2	3.2	With both a horizon and a path cone, the blobs kept are the intersection of the two keep sets; the structural set is governed by the horizon alone, and path cones never elide structure.
HZ-3.3-1	3.3	A horizon serializes into the canonical cone form as one member of a distinct kind carrying C's hash and the rule name, canonically, so the cone's digest stays a valid memoization key.
HZ-3.3-2	3.3	A cone with a horizon member is marked with a version distinct from a cone without one, so that an implementation predating this document refuses rather than misreads it.
HZ-3.4-1	3.4	An origin that offers a default C should also report what each rule would hold.	not yet implemented: the horizon pragmas, Appendix A step 3
HZ-3.4-2	3.4	Clients should not express a horizon as a count or a date at the protocol layer.	not yet implemented: the horizon pragmas, Appendix A step 3
HZ-4.1-1	4.1	A content-horizon clone holds every structural artifact of every age but clusters, every blob an F card of a check-in in the held set names, and elided phantoms for every other blob; it holds, mints and requests no cluster.	covered for check-in manifests and blobs; holding, minting and requesting no cluster awaits cluster suppression, Appendix A step 1
HZ-4.2-1	4.2	A blob is above the horizon when a check-in in the held set names it, directly or through a sub-manifest; elision is the sparse-cone draft's third phantom class with all of its rules: never spontaneously requested, counted distinctly from damage, reclassified by recomputation.
HZ-4.2-2	4.2	A phantom created because a held artifact arrived as a delta against it is a transit phantom whatever its horizon classification.
HZ-4.3-1	4.3	Derived caches and prefix-anchored checkpoints are horizon-independent: their keys do not incorporate the horizon.
HZ-4.4-1	4.4	An operation needing a blob below the horizon resolves the elided phantom by demand fetch, targeted, or by moving C (a deepen).	not yet implemented: the content horizon, Appendix A step 2
HZ-4.5-1	4.5	A horizon clone does not request a phantom whose only reference is a cluster artifact and does not hold the clusters it is sent; it requests phantoms named by igot cards, by the P, F and S cards of held artifacts, and by delta sources of held artifacts.	not yet implemented: cluster suppression, Appendix A step 1
HZ-5.1-1	5.1	A structural-horizon clone holds the manifests and nodes of check-ins in the held set and everything they reach through B and S cards, every control, wiki, ticket, event, forum and attachment artifact, the blobs of the content horizon, elided phantoms for the rest, and the seed, which it keeps from every peer.	not yet implemented: the structural horizon, Appendix A step 5
HZ-5.1-2	5.1	A clone does not enter the structural horizon against a horizon-ignorant peer.	not yet implemented: the structural horizon, Appendix A step 5
HZ-5.2-1	5.2.1	The seed is a control artifact minted by the origin whose T cards apply to every entry of K (C, and each check-in of K whose primary parent is not in K) every tag in force there in the dense repository, each with the value the dense derivation holds; its D card is the time of minting and its U card the origin's login.	not yet implemented: the seed, Appendix A step 5
HZ-5.2-2	5.2.2	The origin sets each seed's D card no earlier than the latest tag event it summarizes and strictly later than any seed it replaces.	not yet implemented: the seed, Appendix A step 5
HZ-5.2-3	5.2.3	A clone never sends its seed to any peer, private-content synchronization included; it holds the seed private or outside the artifact store and applies it at every open.	not yet implemented: the seed, Appendix A step 5
HZ-5.2-4	5.2.3	An origin refuses a seed offered to it, and an artifact of the seed's shape arriving by any route but the horizon reply is an ordinary control artifact.	not yet implemented: the seed, Appendix A step 5
HZ-5.2-5	5.2.4	An origin holding a signing key should sign the seed with the clear-signing envelope.	not yet implemented: the seed, Appendix A step 5
HZ-5.2-6	5.2.4	A clone that knows its origin's public key verifies every seed's signature and discards an unsigned or wrongly signed seed, falling back to the content horizon; a clone with no key accepts an unsigned seed.	not yet implemented: the seed, Appendix A step 5
HZ-5.3-1	5.3	A clone classifies a labelled boundary hash as an elided phantom and an unlabelled unheld reference as a transit phantom, which it requests.	not yet implemented: boundary labels, Appendix A step 5
HZ-5.4-1	5.4	A boundary hash should be rendered as the horizon and is never described as damage; verification reports manifests below the horizon as elided, distinctly from damage.	not yet implemented: the structural horizon, Appendix A step 5
HZ-5.5-1	5.5	An operation needing history below the horizon (a merge base, a symbolic name, a checkout, diff or annotate below C, a bisection) detects the crossing, names the horizon in its diagnostic and offers the stated remedy.	not yet implemented: the structural horizon, Appendix A step 5
HZ-5.5-2	5.5	An implementation never merges against a base it does not hold.	not yet implemented: the merge-base query and deepen, Appendix A step 6
HZ-5.6-1	5.6	A clone requests the seed at each synchronization, naming the seed it holds, and the origin replies with a new seed only when it differs, keeping no per-client state.	not yet implemented: re-seeding, Appendix A step 5
HZ-5.7-1	5.7	A commit from a structural horizon is an ordinary commit: on an existing branch it writes no branch tag; creating a branch it writes the repository-state T cards, the parent branch's cancellation included.	not yet implemented: the structural horizon, Appendix A step 5
HZ-5.7-2	5.7	An origin should check a pushed cancellation against its own derivation and refuse on disagreement, naming the stale seed and the parent's branch; it admits the check-in when the push or its store carries a control artifact cancelling the parent's branch tag on it.	not yet implemented: the push-time check, Appendix A step 6
HZ-5.8-1	5.8	A deepen names an ancestor C' of C, recomputes the held set and synchronizes at C'; nothing held is replaced, and the deepening clone discards the old seed before applying the new one.	not yet implemented: deepen, Appendix A step 6
HZ-5.9-1	5.9	An implementation should offer seed verification by deepening as a verification mode.	not yet implemented: the verification mode, Appendix A step 6
HZ-6.1-1	6.1	A horizon-scoped request carries at most one pragma horizon <hash> <rule>, may carry path-cone pragmas (the keep set is then the intersection), and adds pragma horizon-structural for the structural horizon; any request may carry pragma horizon-cursor.	not yet implemented: the horizon pragmas, Appendix A step 3
HZ-6.2-1	6.2	An origin receiving a horizon pragma computes the held set over the dense graph and restricts the blobs it sends; for a structural request it also restricts manifests and nodes, sends every other structural artifact, the boundary labels and the seed, and bounds the per-round walk.	not yet implemented: the origin's classification, Appendix A step 3
HZ-6.2-2	6.2	An origin should not send cluster artifacts in reply to a horizon-scoped request.	not yet implemented: cluster suppression, Appendix A step 1
HZ-6.2-3	6.2.1	An origin does not send, in reply to a horizon-scoped request, a delta whose base is outside the keep set; it sends that artifact in full, may send in-keep-set deltas verbatim, should bound reconstruction per round, and may send a delta verbatim when it cannot reconstruct it.	not yet implemented: delta inflation, Appendix A step 1
HZ-6.2-4	6.2.2	For a structural request the origin emits pragma horizon-below for every boundary hash, no later than the reply carrying the first manifest that names it.	not yet implemented: boundary labels, Appendix A step 5
HZ-6.2-5	6.2.3	A structural request carries pragma horizon-seed with the held seed or '-'; the origin announces a differing seed with the pragma before its file card; the client verifies the bytes hash to the announced name and parse as a control artifact, drops a card failing either, routes it to its seed holding, and never announces or sends it.	not yet implemented: the seed, Appendix A step 5
HZ-6.2-6	6.2.3	An origin does not advertise the structural level unless it sends a seed in the same reply or the client's offered seed is current, and a seed's D card should be the latest mtime among the tag events it summarizes.	not yet implemented: the seed, Appendix A step 5
HZ-6.2-7	6.2.4	A client may ask pragma horizon-mergebase <a> <b>; an origin answers with the base or '-' and bounds the ancestry walk.	not yet implemented: the merge-base query, Appendix A step 6
HZ-6.2-8	6.2.5	An origin emits pragma horizon-served <level> [<url>] in every reply to a horizon request; a client does not enter the structural horizon unless its first reply carried structural, and should report the mode a transfer used.	not yet implemented: the horizon pragmas, Appendix A step 3
HZ-6.2-9	6.2	An origin should keep its classification keyed by the cone digest and the store prefix it classified, extend it by the artifacts appended since, and recompute in full only when an appended artifact carries a name a held P, B or S card cited while it was absent.	not yet implemented: the origin's classification, Appendix A step 3
HZ-6.2-10	6.2	An origin should read each structural artifact's kind and P, B, S, F and A references once per store into a cone-independent graph keyed to the same prefix, extend it by appended artifacts, and classify every cone over that graph.	not yet implemented: the origin's classification, Appendix A step 3
HZ-6.2-11	6.2.6	An origin that classified a request emits pragma horizon-cursor <n> in every reply, n its artifact-sequence position through which the reply was served; receiving a cursor it announces no artifact at or below it and every kept artifact above it the request did not name, and after a reclassification answers a request carrying a cursor below that position once as if it carried none; it announces with igot only in reply to a request that pulls, and a reply to a push-only request announces nothing, cursor or not.	not yet implemented: the horizon cursor, Appendix A step 3
HZ-6.2-12	6.2.6	A client that converged records the last reply's cursor and its own artifact count per origin and sends the cursor on every request to that origin; it may then announce nothing on a pull-only request, must still announce on a request that sends but may announce only artifacts appended after the recorded count, and advances the count only past artifacts the origin holds.	not yet implemented: the horizon cursor, Appendix A step 3
HZ-6.2-13	6.2.6	The cursor changes what is announced, never what is answered: an origin answers a gimme for any kept artifact whatever cursor the request carried, a client requests every phantom it wants as without one, and either side may drop the cursor and fall back to a full announcement.	not yet implemented: the horizon cursor, Appendix A step 3
HZ-6.3-1	6.3	Against a horizon-ignorant peer a content-horizon client classifies locally, stores the blobs above the horizon, records elided phantoms and reports the counts; a structural request falls back to the content horizon and reports that it did.	not yet implemented: the content horizon, Appendix A step 2
HZ-6.4-1	6.4	A server over a horizon clone refuses a dense clone request, and a horizon request whose held set is not a subset of its own, with one error card and no content; the requesting client treats that reply as fatal.	not yet implemented: the horizon pragmas, Appendix A step 3
HZ-8-1	8	The origin's held-set walk and merge-base query carry the depth and visited-node bounds of any server-side graph walk, and delta inflation on the serve path is bounded by the round's batch limit.	not yet implemented: the origin's classification, Appendix A steps 1 and 3