Skip to content
zit Erratum — draft-fossil-sync-protocol-01 §9.4 / §9.5
Login

Erratum — draft-fossil-sync-protocol-01 §9.4 / §9.5

Document draft-fossil-sync-protocol-01
Section 9.4 — Commit-Lock Pragmas (the server's reply to ci-lock); 9.5 — Private-Content and Discovery Pragmas (the avoid-delta-manifests paragraph)
Type Technical (§9.4 omits a reply the server sends to every ci-lock; §9.5 gives the client the wrong behavior)
Status Applied in draft-fossil-sync-protocol-01 (2026-10-13)
Reported 2026-10-13
Submitter Dan Mestas
Found via Reading Fossil 2.29's page_xfer() ci-lock handler; confirmed by posting ci-lock requests to Fossil 2.28

1. Summary

§9.4 says that after pragma ci-lock the server emits ci-lock-fail on a conflict and otherwise "emits no lock result" and "no positive lock acknowledgement". Fossil's ci-lock handler also emits pragma avoid-delta-manifests whenever the server's forbid-delta-manifests setting is on, which is the default, whether or not the lock was granted. §9.4 does not mention it. The pragma is listed in §9 and described in the last paragraph of §9.5, but that description is wrong: it has the client change which artifacts it sends during the sync. In Fossil the pragma changes no transfer behavior. It makes the client's pending commit write a baseline manifest instead of a delta manifest.

2. Location

§9.4, first paragraph, from "If its stored CLIENT-ID differs" to "a matching live row prevents a new row", and second paragraph, "It emits no positive lock acknowledgement."; §9.5, the paragraph beginning "avoid-delta-manifests is a server-to-client control pragma".

3. The reference behavior

Verified against Fossil 2.29 source; behavior run on Fossil 2.28.

4. Impact

Observable. A server written from §9.4 omits a card Fossil sends on every commit-time autosync. A client written from §9.5 alters its transfer and still writes a delta manifest that a forbid-delta-manifests server asked it to avoid.

5. Correction

§9.4, first paragraph:

    refresh or replacement.  If its stored CLIENT-ID differs from the
    request CLIENT-ID, the server emits pragma ci-lock-fail LOGIN MTIME;
    if it matches, it emits no lock result.  In either case, a matching
-   live row prevents a new row.
+   live row prevents a new row.  After this processing, whether or not
+   a lock was written, the server emits pragma avoid-delta-manifests
+   when its forbid-delta-manifests setting (default on) is true; when
+   ci-lock-fail is emitted, avoid-delta-manifests follows it.  A ci-
+   lock that fails the handler's argument guard emits neither.

§9.4, second paragraph:

-   the current server login value, CLIENT-ID, and current MTIME.  It
-   emits no positive lock acknowledgement.  The transfer dispatcher
+   the current server login value, CLIENT-ID, and current MTIME.  It
+   emits no positive lock acknowledgement; the avoid-delta-manifests
+   pragma above is not one.  The transfer dispatcher

§9.5, the avoid-delta-manifests paragraph:

-   avoid-delta-manifests is a server-to-client control pragma.  Upon
-   receipt, the client removes manifest-delta candidates from any not-
-   yet-dispatched seeded request and sends full manifests for the
-   remainder of the current sync session; it does not affect non-
-   manifest artifacts, already-dispatched data, or persisted repository
-   state.  The flag resets when the session ends.
+   avoid-delta-manifests is a server-to-client pragma with no arguments,
+   sent only in reply to ci-lock (Section 9.4).  It asks the client not
+   to create delta manifests (manifests with a B card, [FossilArtifact])
+   for the commit that requested the lock.  Upon receipt, a client that
+   is about to commit SHOULD write that check-in as a baseline manifest,
+   even if a delta manifest was requested.  The pragma does not change
+   which artifacts the client sends or requests, does not affect
+   artifacts already created, and is not stored in the repository.

6. Rationale

Puts the reply where a server implementer reads the ci-lock handler, with the setting that gates it and its position after ci-lock-fail, and replaces the §9.5 behavior with the one Fossil has: a hint to the commit that triggered the lock, not a transfer rule. SHOULD rather than MUST, because a client that never writes delta manifests has nothing to do.

7. Verification