Artifact aff09a8db110ec8fe3c902a315bf41be69d4bd2112988a612d0528aeb8d1c595:
- File
conformance/requirements/repostate.tsv
— part of check-in
[600861484f]
at
2026-10-13 15:55:30
on branch main
— test(conformance): re-pin the -01 drafts with the 2026-10-13 errata (#430)
* test(conformance): re-pin the -01 drafts with the 2026-10-13 errata
Re-pin the repo-state and sync-protocol drafts to zit check-in 5a1b741b25d8, which applies five more -01 errata: repo-state §5.3, §7.3 and §8.3, sync-protocol §9.4/§9.5 and §10.1. zit now keeps each -01 text under the -00 file name; the copies keep their -01 names and conformance/rfcs/README.md records the zit path and check-in. The new errata are pinned, and the requirement tables are re-read against every changed hunk.
The §7.3 and §8.3 cases that were deviations now pass as written, and new cases cover a date tag's arrival order (§5.3), untagged leaves and a merge parent's recheck (§7.3).
The sync server answers each guard-passing ci-lock with pragma avoid-delta-manifests while forbid-delta-manifests is on, defaulting to on as the draft and fossil 2.29 do (fossil 2.28 defaults it off). The client leaves its transfer unchanged on that pragma. A file or cfile whose content does not match its hash now fails the client's round, in a pull and a clone: the reply rolls back, prefix included, and no further round starts.
The leaf table is still recomputed per crosslink batch, so a parent whose untagged child arrives in a later batch loses the verdict §7.3 keeps; that case is marked as a gap, tracked in #426.
* fix(sync): continue after a uvfile content error; renumber the avoid-delta-manifests row
A uvfile whose content does not match its HASH is a handler-reported content error: warn, commit the prefix and follow ordinary continuation (sync-protocol-01 10.1). The avoid-delta-manifests client row is SP-9.5-7 now that share-links took SP-9.5-5 and SP-9.5-6. Older unreleased changelog entries drop the pending-erratum wording. (user: [email protected], size: 12461) [annotate] [blame] [check-ins using]
# Requirements for draft-fossil-repo-state-01, written from the draft text. # The -01 errata are applied in the draft; they are pinned for the fossil(1) # behavior they record, which RS-4.2-13 and RS-4.2-14 depart from. The errata of # 2026-10-13 (sections 5.3, 7.3 and 8.3) make fossil's behavior the draft's. # draft draft-fossil-repo-state-01.txt d94ba052317b718fdbcff6bda659766dbfd79150a53cfc2feb2b8ace49801f74 # erratum repo-state-01-s4.2-date-tag-event-time.md e55108ed39857f4212c2e0ff4afac867fc42d3b762db58c269790200a33b24cf # erratum repo-state-01-s5.3-inherited-row-blocks-direct-tag.md 2bfd0d2e76efe0bf5b3158527381ecb768df02a3925c83bbf26fee18eb935603 # erratum repo-state-01-s6.2-cancel-cards-from-parent.md 3d24910396abea9e6a162d2578ef58fc033f664fa1a4f778204bf2a1844029aa # erratum repo-state-01-s7.3-leaf-recheck-branch-tag.md 25a27e819bae83cf71ae40e1de09614e2c8fa83c99c94593189da7cd3636e9cc # erratum repo-state-01-s8.3-ckout-ci-plus.md a955cf371e420ebdbcec15ab0d91aca3d25fa494de220af6a186e70192dd53ca # # id section requirement scope RS-2-1 2 An operation that tags a check-in with a user-supplied symbolic name stores it as "sym-" + name unless the caller asks for the raw name. RS-2-2 2 Tags whose names begin with "wiki-", "tkt-" or "event-" are never created by a user tagging operation. RS-3.1-1 3.1 Each parent named on a check-in's P card yields a linkage row (parent, child) carrying the primary-parent flag, the check-in's mtime and the baseline id. RS-3.1-2 3.1 A parent named more than once on one P card yields a single linkage row for that (parent, child) pair. RS-3.1-3 3.1 A delta manifest whose baseline is absent or is not a manifest is not linked: it gets no event or linkage row, and the gap is recorded against the baseline (artifact-format-01 Section 8.3) so it links when the baseline arrives. RS-3.2-1 3.2 The first parent on the P card is the primary parent (flag set); every other parent is a merge parent (flag unset). RS-3.2-2 3.2 A repeated parent keeps the primary flag chosen by its first occurrence. RS-3.2-3 3.2 Linear-history operations (first-parent traversal, the prev keyword) follow only the primary-parent row. RS-3.2-4 3.2 Full-ancestry operations (merge base, ancestor tests) include merge-parent rows. RS-4.1-1 4.1 A manifest with a T-card whose name lacks a -, + or * prefix is rejected. RS-4.1-2 4.1 A manifest with a T-card whose name after the prefix is all hexadecimal digits is rejected. RS-4.1-3 4.1 A manifest whose T-cards are not strictly ascending by (name, uuid) is rejected. RS-4.1-4 4.1 A rejected manifest contributes no tag state at all, not even from its valid T-cards. RS-4.2-1 4.2 A T-card naming an artifact not yet stored resolves to a phantom rid; the tag is recorded against it and is in effect once the artifact arrives and is crosslinked. RS-4.2-2 4.2 A P-card parent not yet stored yields a phantom rid and a linkage row to it, not an error. RS-4.2-3 4.2 T-cards are applied only from control, check-in and technote (event) artifacts. RS-4.2-4 4.2 Crosslinking a cluster applies an implicit singleton "cluster" tag to the cluster itself. RS-4.2-5 4.2 After a check-in with a resolved primary parent is crosslinked, the parent's tags are re-propagated, so the new check-in inherits them. RS-4.2-6 4.2 A T-card of any type applied to a resolved target runs the propagation walk from that target; a singleton enters it as a cancel, removing the same-named tag the descendants inherited. RS-4.2-7 4.2 Crosslinking an artifact again creates no additional linkage or event rows and leaves derived state unchanged. RS-4.2-8 4.2 Singleton reparent operations recorded during a crosslink batch are re-applied when the batch ends. RS-4.2-9 4.2 A date tag applied to a crosslinked check-in sets its stored event time to the tag's value, which otherwise is the D-card time. RS-4.2-10 4.2 A date tag that arrives before its check-in sets the event time when the check-in is crosslinked. RS-4.2-11 4.2 A newer date tag replaces an older one, so the newest date tag's value orders the check-in. RS-4.2-12 4.2 A date tag of any type sets the time of its target only; a propagating date tag does not retime descendants. RS-4.2-13 4.2 Cancelling the date tag restores the D-card time. RS-4.2-14 4.2 A date tag whose value does not parse, or parses to a time that is not positive, is ignored, leaving the D-card time. RS-4.2-15 4.2 The D-card timestamp is retained separately as the original time. RS-4.3-1 4.3 No tag, propagation or linkage effect is applied on behalf of a manifest that fails the T-card checks. RS-4.4-1 4.4 An artifact that hashes to its name but is not classifiable does not make state assembly fail. RS-4.4-2 4.4 An unclassifiable artifact contributes no linkage, tag or branch effect. RS-4.4-3 4.4 An artifact whose bytes do not hash to its stored name is rejected. RS-4.6-1 4.6 A tag or anti-tag operation stores a control artifact with exactly one T-card and derives its state by crosslinking that artifact. RS-5.1-1 5.1 A T-card prefix - is stored as tagtype 0, + as 1 and * as 2. RS-5.1-2 5.1 Any other leading character on a T-card is a fatal error and is never stored as a tag type. RS-5.2-1 5.2 tagxref holds at most one row per (rid, tag), carrying tagtype, srcid, origid, value and mtime. RS-5.3-1 5.3 A direct application is skipped when the (tag, rid) row already has an mtime greater than or equal to the incoming one, whether that row was applied directly or inherited by propagation. RS-5.3-2 5.3 Otherwise the row is replaced with the card's raw tagtype, srcid = the artifact carrying the card, origid = rid = the target. RS-5.3-3 5.3 A cancel application stores a NULL value. RS-5.3-4 5.3 A singleton is propagated as a cancel: it removes the inherited same-name rows of the target's descendants. RS-5.3-5 5.3 When a check-in's ancestor carries a propagating tag newer than a direct tag of the same name on the check-in, the result follows arrival order: the direct tag applied first keeps the direct value and stops the propagation; the propagation arriving first makes the direct tag skipped, so the check-in keeps the inherited value and, for a date tag, its D-card time. RS-5.4-1 5.4 Propagation follows primary-parent links only and never crosses a merge link. RS-5.4-2 5.4 Re-propagating a parent's full tag set treats its singleton rows as cancels. RS-5.4-3 5.4 A child with a same-tag row qualifies only when that row has srcid 0 and an mtime strictly earlier than the propagating tag's; an equal mtime keeps the row. RS-5.4-4 5.4 A child with no same-tag row qualifies for a propagating walk; a cancel walk does not qualify there and does not continue past it. RS-5.4-5 5.4 A qualifying child of a propagating walk gets tagtype 2, srcid 0, the origin's origid, value and mtime. RS-5.4-6 5.4 A qualifying child of a cancel walk has its same-tag row deleted. RS-5.4-7 5.4 Every child updated by the walk is itself walked, so the effect reaches all qualifying primary descendants. RS-5.5-1 5.5 A directly applied same-tag row (srcid nonzero) stops propagation regardless of its mtime. RS-5.5-2 5.5 A cancel tag on a check-in deletes the inherited row there and keeps the tag from its descendants. RS-5.5-3 5.5 A singleton tag on a check-in keeps a same-name propagating tag from its descendants. RS-6.1-1 6.1 A check-in's branch is the value of its branch tag row with tagtype greater than 0. RS-6.1-2 6.1 A check-in with no active branch tag is attributed to the default branch. RS-6.1-3 6.1 Creating a branch, including the default branch of a new repository, creates its sym-<branch> tag, propagating like its branch tag. RS-6.1-4 6.1 The default branch is the main-branch setting, and trunk only when that setting is unset. RS-6.2-1 6.2 Branch creation writes a propagating branch tag with the name as value and a propagating sym-<name> tag on the branch-root check-in. RS-6.2-2 6.2 Branch creation emits a cancel card on the root for every propagating sym-* tag active on the parent other than the new branch's own. RS-6.2-3 6.2 Branch creation fails, before writing anything, when an open branch already has the name. RS-6.3-1 6.3 The branch list has one entry per distinct active branch-tag value, with that value's greatest event.mtime and check-in count. RS-6.3-2 6.3 A listed branch is closed exactly when its representative (greatest event.mtime) check-in carries an active closed tag. RS-6.4-1 6.4 The current branch of a checkout is read with the same tagtype > 0 rule as any branch membership. RS-7.2-1 7.2 A check-in is a leaf exactly when no plink child of it, primary or merge, is on the same branch. RS-7.3-1 7.3 A full leaf rebuild gives the table crosslinking every check-in in one batch gives: the candidates are the check-ins a branch tag is applied or propagated to, and their parents; a candidate with no same-branch child is a member, and a check-in that is not a candidate is not, even with no same-branch child. RS-7.3-2 7.3 An incremental leaf check removes a check-in with a same-branch child and inserts one without, tolerating an existing row. RS-7.3-3 7.3 A branch tag applied to a check-in, or a propagation walk updating or deleting its branch entry, rechecks the check-in and each of its parents, merge parents included; crosslinking a check-in or creating a plink edge schedules no recheck by itself. RS-7.3-4 7.3 Scheduled leaf rechecks have all been applied before the leaf table is read. RS-7.4-1 7.4 An open leaf is a leaf without a closed tag row of tagtype greater than 0. RS-7.5-1 7.5 A branch's open leaves are its leaf-table members that are not closed and share its branch. RS-7.5-2 7.5 The ambiguity test answers no for a check-in that is not itself a leaf. RS-7.5-3 7.5 For a leaf, the ambiguity test answers yes exactly when another open leaf shares its branch. RS-7.6-1 7.6 Directly applying a branch tag re-evaluates that check-in's leaf status. RS-7.6-2 7.6 Each descendant that gains or loses a branch tag by propagation has its leaf status re-evaluated. RS-8.2-1 8.2 A plain name N resolves to the check-in carrying an active sym-N tag with the greatest event.mtime. RS-8.2-2 8.2 A closed tag on a candidate does not affect name resolution. RS-8.2-3 8.2 Whether a candidate is a leaf does not affect name resolution. RS-8.2-4 8.2 A name no form matches fails to resolve. RS-8.3-1 8.3 "rid:DIGITS" resolves to that rid. RS-8.3-2 8.3 "tag:NAME" resolves NAME by the plain-name rule without trying it as a hash. RS-8.3-3 8.3 "tip" resolves to the check-in with the greatest event.mtime. RS-8.3-4 8.3 "current", "prev"/"previous" and "next" resolve relative to the open checkout; "ckout" names the checkout only in a "ci+" request with an open checkout and only as the whole name given, and is otherwise resolved like any other name, the trailing-punctuation retry and the contained names of root:, start: and merge-in: included. RS-8.3-5 8.3 "root:BR" resolves to the first primary ancestor of BR that is off BR's branch. RS-8.3-6 8.3 "start:BR" resolves to the earliest primary ancestor of BR still on BR's branch. RS-8.3-7 8.3 "merge-in:BR" resolves to the most recent merge-in point of BR from its parent branch. RS-8.3-8 8.3 Date forms and NAME:TIMESTAMP resolve to the latest eligible event with mtime at or below the expanded upper bound. RS-8.3-9 8.3 A hexadecimal name of 4 or more digits is tried as a hash prefix before the plain-name rule. RS-8.3-10 8.3 A hash prefix matching more than one artifact is rejected as ambiguous. RS-8.3-11 8.3 A name that matches nothing is retried without one trailing . _ ) > ! ? or , when longer than four characters, or without two when longer than five; three or more are never stripped. RS-8.3-12 8.3 A branch-type request resolves to the first check-in of the branch the name resolves into. RS-8.5-1 8.5 Name resolution and open-leaf enumeration stay distinct: a newer closed sym carrier wins resolution while the leaf view omits it. RS-9-1 9 The current trunk is the main-branch setting's name resolved by the Section 8 symbolic-name procedure. RS-9-2 9 Resolving a forked branch picks one check-in by greatest mtime and is not an error. RS-9-3 9 A branch's open leaf carries its active branch tag, is in the leaf table and is not closed; a branch with none is not open. RS-9-4 9 A report naming one open leaf of a branch with several picks the greatest mtime. RS-12-1 12 An artifact that the artifact-format rules reject contributes no crosslink state.