Repository navigation
feat(index): warm-started --from syncs (D21) - #21
Merged
Merged
Conversation
The receiver-side --from sync now indexes the OLD file at commit (its own identity: its size, its mtime, its chunks) on both conversation outcomes — executed plan (the old file's chunks were hash-verified as plan reads this session) and empty-plan match (the scan already ran). A repeated --from sync against the same old file then warm-starts the receiver's scan, which the old code re-paid on every run. Measured (the --warm cell; the mechanism — same index, same load path — is identical for either side): 128 MiB fixture, cold scan 116.53 ms vs warm load 488.50 us = 238.6x. Disk-bound, scales with size. The broader idea this replaces — an index snapshot a fresh machine could request to turn first-sync into a delta — was analyzed and REJECTED (D21): an index carries chunk lists, not bytes; every PLAN_LOCAL entry is a byte-verified read from the receiver's own temp/old file, so a manifest of unbacked chunks cannot produce Local entries and degrades to the full transfer we already have. Migration is a bulk-copy problem (out of niche, D9). Rename detection (cross-file chunk manifests) is recorded as the future wire feature. Test: from_sync_writes_old_file_index_and_repeat_warm_starts — index identity per file, the target never indexed from foreign content, repeated --from emits WarmStart. Docs: D21 ledger entry, CHANGELOG.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Implements the one surviving piece of the warm-start design pass (D21 in the design ledger): the receiver-side
--fromsync indexes the old file at commit, so a repeated--fromsync against the same old file warm-starts the receiver's scan (previously re-paid on every run). Measured: 238.6× on the 128 MiB fixture (116.53 ms cold scan → 488.50 µs warm load) — disk-bound, scales with size.What was rejected, and why (the analysis is the point)
The outlook's "index snapshot a fresh machine could request" idea does not survive analysis: an index carries chunk lists (hash/offset/length), not bytes. Every
PLAN_LOCALentry is a byte-verified read from the receiver's own temp/old file — a fresh machine has neither, so a served manifest of unbacked chunks produces zero Local entries and degrades to exactly the full transfer we have today. Migration is a bulk-copy problem (out of niche, D9). Rename detection (cross-file chunk manifests) is recorded as the genuine future wire feature.Verification
from_sync_writes_old_file_index_and_repeat_warm_starts: the old-file index carries its own identity (size/mtime/chunks), the target is never indexed from foreign content, and the repeated sync emitsWarmStart.-D warnings, all suites (loopback 23, tree 27, tls/quic/soak/integration).