Add content_hash tracking and extract composer package (Phase 1)#74
Open
swalkinshaw wants to merge 1 commit intomainfrom
Open
Add content_hash tracking and extract composer package (Phase 1)#74swalkinshaw wants to merge 1 commit intomainfrom
swalkinshaw wants to merge 1 commit intomainfrom
Conversation
Foundation for incremental sync: compute and store content hashes at update time so the future sync step can diff against deployed_hash to find what needs uploading to R2. - Migration 024: add content_hash, deployed_hash, content_changed_at columns to packages table - Extract internal/composer/ from internal/repository/ (format.go, serialize.go, hash.go) — pure functions for Composer serialization and hashing with no I/O - Add SerializePackage() for tagged/dev file splitting and HashVersions() for lightweight content hashing - Compute content_hash in update step after NormalizeAndStoreVersions; only advance content_changed_at when hash actually changes - Hash includes trunk_revision so dev-trunk SVN reference changes trigger re-sync - repository/ re-exports from composer/ for builder.go compatibility Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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
1 participant
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.
Phase 1 of #52
Foundation for incremental sync: compute and store content hashes at update time so the future sync step can diff against
deployed_hashto find what needs uploading to R2.content_hash,deployed_hash,content_changed_atcolumns to packages tableinternal/composer/module - pure functions for Composer serialization and hashing with no I/OSerializePackage()for tagged/dev file splitting andHashVersions()for lightweight content hashingcontent_hashin update step afterNormalizeAndStoreVersions; only advancecontent_changed_atwhen hash actually changestrunk_revisionso dev-trunk SVN reference changes trigger re-syncThis has no breaking changes by design and does not populate new data yet. Backfill of the new columns with happen naturally during builds + deploys.