Skip to content
go-libfossil Ambiguous Artifact ID
Login

Ambiguous Artifact ID

The artifact hash prefix 48ab is ambiguous and might mean any of the following:

  1. 48ab119fd1f71d0888bccb9e6fdae67cf62581c367cf3ec5dbe19c8ecb7334f5 -

    • File internal/sync/handler.go — part of check-in [1fd6c06a65] at 2026-07-24 14:19:29 on branch trunk — sync: emit clone push card after clone_seqno to stop real-client re-clone (#138) (#149)

      A stock fossil 2.28 client cloning a go-libfossil server transferred ~2.06x the repository's stored size, while the server's own response bodies measure 1.04x and a fossil-serving-fossil control measures 1.03x. The gap was a full second content-transfer pass, not a card-encoding problem.

      Root cause is card order. Canonical's client re-issues `clone 3 SEQNO` every round it sees a server `push` card while its clone cursor is still positive (xfer.c:2706), and it learns the cursor reached zero only from the clone_seqno card. Canonical's server therefore emits the batch, then clone_seqno (xfer.c:1571), then push (xfer.c:1577). go-libfossil emitted push *first*, so the client queued one more clone request before it processed the terminal clone_seqno 0 — and the server served the entire repository a second time.

      Relocate the clone-mode push-card emission to after processDataCards so it trails the batch's clone_seqno card, matching canonical's order. The clone now completes in a single content pass: re-measured end-to-end at 1.03x stored, identical to the fossil control (1.00x ratio). (user: [email protected], size: 35033) [annotate] [blame] [check-ins using]

  2. 48abc8eb8eb15bdc38b69b3e4efe3857de5379d1c88ff8646ac98de85b3ae0fa -

    • File conformance/requirements/sync.tsv — part of check-in [2cb62c37bc] at 2026-10-11 20:59:25 on branch main — test(conformance): sync suite follows the s7.3 uvgimme Read erratum (#313)

      The new erratum to draft-fossil-sync-protocol-00 §7.3 has the server answer uvgimme only for a requester with Read, with Clone implying Read, and refuse silently otherwise. fossil 2.28 answers any uvgimme.

      - The erratum is copied unmodified into conformance/rfcs/erratum and pinned in requirements/sync.tsv, with two new requirements, SP-7.3-11 and SP-7.3-12. - Server cases can carry a fossil note again: a case that expects something fossil(1) does not do says why, and fails once fossil(1) does it. sync.7.3.uvgimme-no-read uses it, so the case flags the day CI's pinned fossil takes the matching patch. - sync.7.3.uvgimme-clone-implies-read finds that go-libfossil's read gates ignore Clone; it is marked as a gap, tracked in #312. (user: [email protected], size: 20530) [annotate] [blame] [check-ins using]