| Comment: | timeline: read fossil-legacy check-in manifests instead of dropping them
Repository.manifest parsed check-in manifests through the strict reference parser, which rejects fossil's own 2008 cvs2fossil-era manifests: their F cards carry a dangling trailing space after the hash, where the §4.2 perm token (1*tchar) permits none. On a large fossil-origin repository this made `zit timeline` stop at the first such check-in and exit non-zero, silently losing that check-in and every older one — a functional loss of history, surfaced as a misleading "input/output error". Parse through parseForImport, the same read-path interop the diff baseline already relies on: the strict parser still runs first and stays the sole grammar oracle; the trailing-separator tolerance engages only when an otherwise well-framed, Z-valid artifact is rejected. OwnedManifest now also owns the normalized copy the manifest borrows when that tolerance fires. |
|---|---|
| Timelines: | family | ancestors | descendants | both | iss7 |
| Files: | files | file ages | folders |
| SHA3-256: |
b503efb9f254d8c11a9d9171ac29f8ce |
| User & Date: | dmestas on 2026-07-19 21:36:07.116 |
| Other Links: | branch diff | manifest | tags |
|
2026-07-19
| ||
| 21:52 |
Merge iss7: read fossil's legacy check-ins instead of dropping history
timeline stopped partway through a large fossil-origin repository and lost every check-in at and beyond that point. The cause was not an I/O fault, as the shared "input/output error" wording suggested, but a strict parse: fossil's own 2008 cvs2fossil-era check-ins carry F cards with a dangling trailing separator after the hash, which the §4.2 grammar has no production for and the reference parser rejects as corrupt. Repository.manifest -- the timeline read path -- used that strict parser, so the first such check-in and all older ones vanished. It now reads through parseForImport, the same read-path tolerance the diff baseline already relies on. The strict parser still runs first and stays the sole grammar oracle; tolerance engages only when a well-framed, Z-valid artifact is rejected, strips exactly one trailing separator per F card, re-seals the checksum, and re-runs the strict parser -- so any other malformation is still refused. Complete history renders again, down to the repository's 2007 root. check-in: 4e8d402bb6 user: dmestas tags: trunk | |
| 21:36 |
timeline: read fossil-legacy check-in manifests instead of dropping them
Repository.manifest parsed check-in manifests through the strict reference parser, which rejects fossil's own 2008 cvs2fossil-era manifests: their F cards carry a dangling trailing space after the hash, where the §4.2 perm token (1*tchar) permits none. On a large fossil-origin repository this made `zit timeline` stop at the first such check-in and exit non-zero, silently losing that check-in and every older one — a functional loss of history, surfaced as a misleading "input/output error". Parse through parseForImport, the same read-path interop the diff baseline already relies on: the strict parser still runs first and stays the sole grammar oracle; the trailing-separator tolerance engages only when an otherwise well-framed, Z-valid artifact is rejected. OwnedManifest now also owns the normalized copy the manifest borrows when that tolerance fires. closed check-in: b503efb9f2 user: dmestas tags: iss7 | |
| 17:32 |
Merge blockers: a failed mv changes nothing, and its recovery is exact (B4)
mv recorded a rename in the managed set and persisted it before attempting the filesystem move, with no rollback. A move into a nonexistent directory left the set naming a path that held no file: status invented a missing entry, commit refused over it, and the recovery mv --help documents did not work. mv now validates that the destination's parent exists and refuses before touching anything, so the failing case records nothing. Two further defects on the same path. An inverse rename replaced the pending record instead of dropping it, so 'mv a b' followed by 'mv b a' left a b-to-a rename queued; the next commit carrying a real change would then emit an old-name F card asserting the file was formerly named b, a name never committed. That is false provenance in a permanent artifact, produced by the exact sequence the help text advertises as recovery. mvRecord now nets an inverse rename back out. The error path printed raw Zig error names — a user saw 'AccessDenied' where clean and init already print 'permission denied' through reasonOf. It now uses the same mapping. A residual window remains: a crash between the move and the record write is not atomic, documented at the site. Full working-tree crash consistency is a separate concern. check-in: 33a2ceb6d1 user: dmestas tags: trunk | |