From 515a88801be5080171c279a4b9045bb633963e8e Mon Sep 17 00:00:00 2001 From: dayfine Date: Thu, 29 Oct 2026 11:35:54 -0700 Subject: [PATCH 1/7] Notes: measure local build and lab deployment disk use, and compare ways to share Resources Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E --- docs/notes/LabBuildDiskUsage.md | 57 +++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 docs/notes/LabBuildDiskUsage.md diff --git a/docs/notes/LabBuildDiskUsage.md b/docs/notes/LabBuildDiskUsage.md new file mode 100644 index 0000000000..f2a6908dbd --- /dev/null +++ b/docs/notes/LabBuildDiskUsage.md @@ -0,0 +1,57 @@ +# Disk use of local builds and lab deployments + +Goal: keep many builds (dozens of lab deployments, several worktrees) within a +few GiB, without risking one build running with another build's files. + +## Measured (2026-10-29, Apple Silicon) + +| What | Size each | Notes | +|---|---|---| +| Worktree build directory | 2.1 GB | 1.0 GB objects, 0.9 GB `libSerialProgramsLib.a`, 0.2 GB `Resources` | +| Lab deployment (`~/BDSPLab/builds/`) | 334 MB | 300 MB `Resources`, 30 MB `.app` | +| Shared ccache (`macos-ccache` preset) | 0.76 GB total | about 250 MB per fully rebuilt revision; capped at 5 GB | + +The ccache preset (PokemonAutomation/Arduino-Source#1767) makes rebuilds fast. It +doesn't make any of these smaller. Today `~/BDSPLab/builds` holds 12 +deployments (6 builds, each with a console-B copy) in 3.7 GB, almost all of it +copies of `Resources`. + +## What the app already allows + +`get_resource_path()` (`CommonFramework/GlobalAutoPaths.cpp`) looks for a +`Resources/` folder next to the executable and then up to five parent folders. +A deployment can therefore use a `Resources` folder it doesn't own, without +any code change. + +## Options + +1. **One `Resources` folder shared by every deployment.** This is the smallest: + each build is about 30 MB. The risk is version skew. Resources change between + revisions (models, JSON, images), so an older build would silently read newer + files. Rejected. +2. **Content-addressed snapshots.** Hash the `Resources` tree at deploy time and + store it once as `builds/resources//`, which is never modified. Each + deployment's `Resources` is a symlink to its snapshot, so builds with + identical resources share one copy and a changed tree gets a new snapshot. + Pruning deletes snapshots that no deployment links to. +3. **APFS clones (`cp -c`).** Each deployment is an independent copy, and + identical blocks share disk until written. There is no sharing risk and the + change is one flag. Drawbacks: macOS/APFS only, and `du` reports full sizes, so + savings show only in `df`. +4. **Hard links (`rsync --link-dest`).** Unchanged files are shared and changed + files are copied. Writing a file in place would change it in every + deployment, and nothing guards against that. +5. **Worktree build directories.** With ccache a full rebuild at a cached + revision takes about 40 s, so idle worktrees can drop `build/` entirely + instead of keeping 2 GB of objects each. + +## Proposal + +Use option 2 for lab deployments and option 5 for worktrees that have been idle +for more than a few days, then measure with `df` before and after. + +Open questions: +- Should the console-B copy (`-B`) share the `.app` too? Today it is a + second signed copy with a different bundle id. +- Should `Resources` hashing skip files the app writes at runtime, if any? +- Keep this in lab scripts only, or document it next to the ccache guide? From d887e39b8d3e0e548a991e0da58e423678e95036 Mon Sep 17 00:00:00 2001 From: dayfine Date: Thu, 29 Oct 2026 13:29:42 -0700 Subject: [PATCH 2/7] Notes: measure the disk options on seven lab builds Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E --- docs/notes/LabBuildDiskUsage.md | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/docs/notes/LabBuildDiskUsage.md b/docs/notes/LabBuildDiskUsage.md index f2a6908dbd..157f1c586c 100644 --- a/docs/notes/LabBuildDiskUsage.md +++ b/docs/notes/LabBuildDiskUsage.md @@ -45,10 +45,34 @@ any code change. revision takes about 40 s, so idle worktrees can drop `build/` entirely instead of keeping 2 GB of objects each. +## Trial (2026-10-29) + +Seven lab builds, each with its console-B copy, deployed five ways into a +scratch folder. Disk use was measured with `df`, which counts shared blocks +once. The seven builds hold only two distinct `Resources` trees: BDSP's, with +1,467 files (300 MB), and upstream's, with 686 files (199 MB). + +| Option | Disk for 14 deployments | +|---|---| +| Plain copy (today) | 4,212 MB | +| 1. One shared `Resources` | 718 MB, but 2 of the 7 builds would read the other branch's files | +| 2. Content-hash snapshots + symlink | 912 MB: 500 MB of trees plus 420 MB of `.app` copies | +| 3. APFS clones (`cp -c`) | about 0 MB, cloned from existing deployments | +| 4. Hard links (`pax -rwl`) | 965 MB | + +Notes: +- macOS ships openrsync, which didn't hard-link with `rsync --link-dest`. +- The clone result is a best case. A real deploy clones from the build + folder; if a build rewrites `Resources` (not yet checked), each new + revision costs a full copy again. +- Snapshots dedupe by content, so they stay at one copy per distinct tree + whatever the build does. + ## Proposal -Use option 2 for lab deployments and option 5 for worktrees that have been idle -for more than a few days, then measure with `df` before and after. +Use option 2 for `Resources` and option 3 for the `.app` copies: about 500 MB +here instead of 4.2 GB, with no change to the app. Use option 5 for worktrees +that have been idle for more than a few days. Open questions: - Should the console-B copy (`-B`) share the `.app` too? Today it is a From ba8322558248bf757a98bc07bf9aeab9f6b53be1 Mon Sep 17 00:00:00 2001 From: dayfine Date: Thu, 29 Oct 2026 13:34:13 -0700 Subject: [PATCH 3/7] Notes: builds rewrite Resources, so prefer snapshots over clones for it Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E --- docs/notes/LabBuildDiskUsage.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/docs/notes/LabBuildDiskUsage.md b/docs/notes/LabBuildDiskUsage.md index 157f1c586c..ad7067e3d5 100644 --- a/docs/notes/LabBuildDiskUsage.md +++ b/docs/notes/LabBuildDiskUsage.md @@ -62,20 +62,25 @@ once. The seven builds hold only two distinct `Resources` trees: BDSP's, with Notes: - macOS ships openrsync, which didn't hard-link with `rsync --link-dest`. -- The clone result is a best case. A real deploy clones from the build - folder; if a build rewrites `Resources` (not yet checked), each new - revision costs a full copy again. +- The clone result is a best case and doesn't hold for real deploys. Every + build re-copies the whole `Resources` folder into the build directory: all + 686 files carry the time of the last link. A clone taken from the build + folder after a rebuild therefore shares nothing with older deployments, and + each deploy costs a full `Resources` (200-300 MB). - Snapshots dedupe by content, so they stay at one copy per distinct tree whatever the build does. ## Proposal -Use option 2 for `Resources` and option 3 for the `.app` copies: about 500 MB -here instead of 4.2 GB, with no change to the app. Use option 5 for worktrees -that have been idle for more than a few days. +- **`Resources`:** option 2, content-hash snapshots. Stored once per distinct + tree, so it doesn't matter that builds rewrite the folder. +- **`.app`:** option 3, APFS clones. The console-B copy can be cloned from the + console-A copy before its plist edit and re-signing, so only the changed + blocks take space (not yet measured). +- **Worktrees:** option 5 for worktrees idle more than a few days. + +Here that is about 500 MB instead of 4.2 GB, with no change to the app. Open questions: -- Should the console-B copy (`-B`) share the `.app` too? Today it is a - second signed copy with a different bundle id. - Should `Resources` hashing skip files the app writes at runtime, if any? - Keep this in lab scripts only, or document it next to the ccache guide? From b0b3da95337b15a67c08d7a0c973150d420f10ab Mon Sep 17 00:00:00 2001 From: dayfine Date: Thu, 29 Oct 2026 18:41:17 -0700 Subject: [PATCH 4/7] Notes: what was adopted for lab disk use, and lab output Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E --- docs/notes/LabBuildDiskUsage.md | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/docs/notes/LabBuildDiskUsage.md b/docs/notes/LabBuildDiskUsage.md index ad7067e3d5..8fd8fb3205 100644 --- a/docs/notes/LabBuildDiskUsage.md +++ b/docs/notes/LabBuildDiskUsage.md @@ -70,17 +70,29 @@ Notes: - Snapshots dedupe by content, so they stay at one copy per distinct tree whatever the build does. -## Proposal +## Adopted (2026-10-29) -- **`Resources`:** option 2, content-hash snapshots. Stored once per distinct - tree, so it doesn't matter that builds rewrite the folder. -- **`.app`:** option 3, APFS clones. The console-B copy can be cloned from the - console-A copy before its plist edit and re-signing, so only the changed - blocks take space (not yet measured). -- **Worktrees:** option 5 for worktrees idle more than a few days. +- **`Resources`:** content-hash snapshots in `~/BDSPLab/builds/.resources//`, + linked from each deployment; a prune keeps the 5 newest deployments per build + family (`bdsp-r105` and `frlgnav8` are families `bdsp-r` and `frlgnav`) and + deletes snapshots nothing links to. +- **`.app`:** APFS clones for the console-B copy. +- **Worktrees:** build directories only for worktrees in use; the others are + deleted and rebuilt from ccache when needed (about a minute). -Here that is about 500 MB instead of 4.2 GB, with no change to the app. +Result: 12 deployments (two build families, with console-B copies) take 587 MB, +199 MB of it the one snapshot they share, against 4.2 GB for 14 before. Three +worktree build directories in use take 6.4 GB. + +## Lab output + +What the lab apps write grows faster than the builds and isn't covered above: +per-leg route screenshots and move screenshots from AutoStory runs (2.2 GB in +the console-B profile after two days), Command File Runner probe shots (1 GB, +cleared), and rotated logs. These are run evidence, not build output, so they +are cleared by hand after a run is recorded. Open questions: - Should `Resources` hashing skip files the app writes at runtime, if any? - Keep this in lab scripts only, or document it next to the ccache guide? +- Should AutoStory keep per-leg screenshots only for failed runs? From 1f792f4a7a01f2aeea89081d4d99a629aed5c782 Mon Sep 17 00:00:00 2001 From: dayfine Date: Thu, 29 Oct 2026 20:35:43 -0700 Subject: [PATCH 5/7] Notes: pitfalls of sharing Packages and deleting lab folders Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E --- docs/notes/LabBuildDiskUsage.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/notes/LabBuildDiskUsage.md b/docs/notes/LabBuildDiskUsage.md index 8fd8fb3205..a2d64be80b 100644 --- a/docs/notes/LabBuildDiskUsage.md +++ b/docs/notes/LabBuildDiskUsage.md @@ -84,6 +84,22 @@ Result: 12 deployments (two build families, with console-B copies) take 587 MB, 199 MB of it the one snapshot they share, against 4.2 GB for 14 before. Three worktree build directories in use take 6.4 GB. +## Pitfalls found on 2026-10-29 + +- **A build's `Resources` come from its worktree's `Packages`.** Sharing one `Packages` checkout + between worktrees (a link) saves 0.8 to 1.1 GB each, but only where the branches need the same + resources. BDSP AutoStory needs its own set (1,467 files, with #1717's 789 AutoStory templates); + a worktree linked to upstream's set (686 files) built fine and then failed at run time with + "FileException: Unable to open file" on the first missing template. +- **`Resources` is copied once.** The copy is a post-build step that runs only when the build + directory has no `Resources` yet, so pointing a worktree at another `Packages` doesn't refresh + it: delete `/Resources` and rebuild, or copy it by hand. +- **Deployments aren't self-contained.** The app finds `onnxruntime` through an rpath into the + worktree it was built in. Deleting an idle worktree's build directory is safe; deleting the + worktree breaks every deployment built from it (dyld "Library not loaded"). +- **Look for links before deleting a folder.** Lab profiles linked their `DownloadedResources` to + one profile's copy; deleting that copy broke resource downloads in six profiles. + ## Lab output What the lab apps write grows faster than the builds and isn't covered above: From 92a69ed41dbd3dffbd1ed6f693d7f537e13a9d1b Mon Sep 17 00:00:00 2001 From: dayfine Date: Thu, 29 Oct 2026 20:37:08 -0700 Subject: [PATCH 6/7] Notes: say which disk techniques work and which don't Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E --- docs/notes/LabBuildDiskUsage.md | 82 +++++++++------------------------ 1 file changed, 23 insertions(+), 59 deletions(-) diff --git a/docs/notes/LabBuildDiskUsage.md b/docs/notes/LabBuildDiskUsage.md index a2d64be80b..0a840e4ef1 100644 --- a/docs/notes/LabBuildDiskUsage.md +++ b/docs/notes/LabBuildDiskUsage.md @@ -23,65 +23,29 @@ copies of `Resources`. A deployment can therefore use a `Resources` folder it doesn't own, without any code change. -## Options - -1. **One `Resources` folder shared by every deployment.** This is the smallest: - each build is about 30 MB. The risk is version skew. Resources change between - revisions (models, JSON, images), so an older build would silently read newer - files. Rejected. -2. **Content-addressed snapshots.** Hash the `Resources` tree at deploy time and - store it once as `builds/resources//`, which is never modified. Each - deployment's `Resources` is a symlink to its snapshot, so builds with - identical resources share one copy and a changed tree gets a new snapshot. - Pruning deletes snapshots that no deployment links to. -3. **APFS clones (`cp -c`).** Each deployment is an independent copy, and - identical blocks share disk until written. There is no sharing risk and the - change is one flag. Drawbacks: macOS/APFS only, and `du` reports full sizes, so - savings show only in `df`. -4. **Hard links (`rsync --link-dest`).** Unchanged files are shared and changed - files are copied. Writing a file in place would change it in every - deployment, and nothing guards against that. -5. **Worktree build directories.** With ccache a full rebuild at a cached - revision takes about 40 s, so idle worktrees can drop `build/` entirely - instead of keeping 2 GB of objects each. - -## Trial (2026-10-29) - -Seven lab builds, each with its console-B copy, deployed five ways into a -scratch folder. Disk use was measured with `df`, which counts shared blocks -once. The seven builds hold only two distinct `Resources` trees: BDSP's, with -1,467 files (300 MB), and upstream's, with 686 files (199 MB). - -| Option | Disk for 14 deployments | -|---|---| -| Plain copy (today) | 4,212 MB | -| 1. One shared `Resources` | 718 MB, but 2 of the 7 builds would read the other branch's files | -| 2. Content-hash snapshots + symlink | 912 MB: 500 MB of trees plus 420 MB of `.app` copies | -| 3. APFS clones (`cp -c`) | about 0 MB, cloned from existing deployments | -| 4. Hard links (`pax -rwl`) | 965 MB | - -Notes: -- macOS ships openrsync, which didn't hard-link with `rsync --link-dest`. -- The clone result is a best case and doesn't hold for real deploys. Every - build re-copies the whole `Resources` folder into the build directory: all - 686 files carry the time of the last link. A clone taken from the build - folder after a rebuild therefore shares nothing with older deployments, and - each deploy costs a full `Resources` (200-300 MB). -- Snapshots dedupe by content, so they stay at one copy per distinct tree - whatever the build does. - -## Adopted (2026-10-29) - -- **`Resources`:** content-hash snapshots in `~/BDSPLab/builds/.resources//`, - linked from each deployment; a prune keeps the 5 newest deployments per build - family (`bdsp-r105` and `frlgnav8` are families `bdsp-r` and `frlgnav`) and - deletes snapshots nothing links to. -- **`.app`:** APFS clones for the console-B copy. -- **Worktrees:** build directories only for worktrees in use; the others are - deleted and rebuilt from ccache when needed (about a minute). - -Result: 12 deployments (two build families, with console-B copies) take 587 MB, -199 MB of it the one snapshot they share, against 4.2 GB for 14 before. Three +## What works and what doesn't + +Tried on 2026-10-29 with seven lab builds, each with its console-B copy, deployed into a scratch +folder and measured with `df` (which counts shared blocks once). The seven builds hold two distinct +`Resources` trees: BDSP's (1,467 files, 300 MB) and upstream's (686 files, 199 MB). A plain copy of +all 14 deployments took 4,212 MB. + +| Technique | Works? | Disk for 14 | Why | +|---|---|---|---| +| Content-hash `Resources` snapshots, linked from each deployment | **Yes, in use** | 912 MB (500 MB of trees, 420 MB of `.app`) | One copy per distinct tree, whatever the build does; a deployment can only see the tree it was built with | +| APFS clones (`cp -c`) for the console-B `.app` copy | **Yes, in use** | the second copy is close to free | Clones of a just-made copy share blocks. macOS only, and `du` shows full sizes (use `df`) | +| APFS clones for `Resources` across deployments | No | ~0 in the trial, a full tree per deploy in practice | Every build re-copies `Resources`, so a clone from a fresh build shares nothing with older deployments | +| One `Resources` folder for all deployments | No | 718 MB | Version skew: 2 of the 7 builds would silently read the other branch's files | +| Hard links (`pax -rwl`) | No | 965 MB | Not smaller than snapshots, and writing one file in place changes it in every deployment. macOS's openrsync didn't link with `--link-dest` at all | +| Dropping idle worktrees' build directories | **Yes, in use** | 2.1 GB each | ccache rebuilds a cached revision in about a minute. Keep the worktree itself (see Pitfalls) | +| Sharing one `Packages` checkout between worktrees | **Only for the same resource set** | 0.8 to 1.1 GB each | Saves a copy where branches need the same resources; wrong for branches with their own (BDSP), see Pitfalls | + +## In use now + +`~/BDSPLab/bdsp_deploy.sh` stores `Resources` as snapshots in `builds/.resources//` and clones +the console-B copy; `prune_builds.sh` keeps the 5 newest deployments per build family (`bdsp-r105` +and `frlgnav8` are families `bdsp-r` and `frlgnav`) and deletes snapshots nothing links to. Result: +12 deployments take 587 MB (199 MB of it one shared snapshot) instead of 4.2 GB, and the three worktree build directories in use take 6.4 GB. ## Pitfalls found on 2026-10-29 From fb5be6d44a668230e6b7e27ce13daf49afe0657e Mon Sep 17 00:00:00 2001 From: dayfine Date: Thu, 29 Oct 2026 20:40:15 -0700 Subject: [PATCH 7/7] Notes: definitive recommendations for lab disk use, no open questions Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01AKYzhrMnPK61XHWEch4a6E --- docs/notes/LabBuildDiskUsage.md | 134 ++++++++++++++------------------ 1 file changed, 59 insertions(+), 75 deletions(-) diff --git a/docs/notes/LabBuildDiskUsage.md b/docs/notes/LabBuildDiskUsage.md index 0a840e4ef1..8f9df1fbb5 100644 --- a/docs/notes/LabBuildDiskUsage.md +++ b/docs/notes/LabBuildDiskUsage.md @@ -1,78 +1,62 @@ # Disk use of local builds and lab deployments -Goal: keep many builds (dozens of lab deployments, several worktrees) within a -few GiB, without risking one build running with another build's files. - -## Measured (2026-10-29, Apple Silicon) - -| What | Size each | Notes | +Goal: keep many builds (dozens of lab deployments, several worktrees) within a few GiB, without +one build ever running with another build's files. Measured on Apple Silicon, 2026-10-29. + +## Do this + +1. **Store each deployment's `Resources` as a content-hash snapshot**, linked from the deployment + (`~/BDSPLab/builds/.resources//`, made by `snapshot_resources.sh` from `bdsp_deploy.sh`). + Builds with identical resources share one copy; a changed tree gets a new snapshot, so no build + sees another branch's files. The app only reads `Resources` (`get_resource_path()` looks for it + next to the executable and up to five parents; downloads go to the profile's + `DownloadedResources`), and no snapshot had a file modified after a day of runs. +2. **Make the console-B copy of a deployment with APFS clones** (`cp -c`, in `make_slot_b.sh`). + It costs almost nothing; check savings with `df`, since `du` counts clones in full. +3. **Prune deployments to the 5 newest per build family** (`prune_builds.sh`: `bdsp-r105` and + `frlgnav8` are families `bdsp-r` and `frlgnav`) and delete snapshots nothing links to. +4. **Keep build directories only for worktrees in use**, with the `macos-ccache` preset + (PokemonAutomation/Arduino-Source#1767): a cached revision rebuilds in about a minute, so an + idle worktree's 2.1 GB `build/` can go. Keep the worktree itself (see "Don't"). +5. **Share a `Packages` checkout only between worktrees that need the same resource set.** + Upstream branches can link to one checkout; BDSP AutoStory branches use `~/BDSPLab/packages`. +6. **Clear lab run output after the run is recorded**: AutoStory route and move screenshots (keep + `failures/` and `saves/`), Command File Runner probe shots, and old logs. They grow faster than + the builds (2.2 GB of AutoStory screenshots in two days). + +These stay in the lab scripts; the ccache guide (#1767) covers the only part upstream needs. + +## Don't + +| Technique | Why it fails | Measured (14 deployments; plain copies 4,212 MB) | |---|---|---| -| Worktree build directory | 2.1 GB | 1.0 GB objects, 0.9 GB `libSerialProgramsLib.a`, 0.2 GB `Resources` | -| Lab deployment (`~/BDSPLab/builds/`) | 334 MB | 300 MB `Resources`, 30 MB `.app` | -| Shared ccache (`macos-ccache` preset) | 0.76 GB total | about 250 MB per fully rebuilt revision; capped at 5 GB | - -The ccache preset (PokemonAutomation/Arduino-Source#1767) makes rebuilds fast. It -doesn't make any of these smaller. Today `~/BDSPLab/builds` holds 12 -deployments (6 builds, each with a console-B copy) in 3.7 GB, almost all of it -copies of `Resources`. - -## What the app already allows - -`get_resource_path()` (`CommonFramework/GlobalAutoPaths.cpp`) looks for a -`Resources/` folder next to the executable and then up to five parent folders. -A deployment can therefore use a `Resources` folder it doesn't own, without -any code change. - -## What works and what doesn't - -Tried on 2026-10-29 with seven lab builds, each with its console-B copy, deployed into a scratch -folder and measured with `df` (which counts shared blocks once). The seven builds hold two distinct -`Resources` trees: BDSP's (1,467 files, 300 MB) and upstream's (686 files, 199 MB). A plain copy of -all 14 deployments took 4,212 MB. - -| Technique | Works? | Disk for 14 | Why | -|---|---|---|---| -| Content-hash `Resources` snapshots, linked from each deployment | **Yes, in use** | 912 MB (500 MB of trees, 420 MB of `.app`) | One copy per distinct tree, whatever the build does; a deployment can only see the tree it was built with | -| APFS clones (`cp -c`) for the console-B `.app` copy | **Yes, in use** | the second copy is close to free | Clones of a just-made copy share blocks. macOS only, and `du` shows full sizes (use `df`) | -| APFS clones for `Resources` across deployments | No | ~0 in the trial, a full tree per deploy in practice | Every build re-copies `Resources`, so a clone from a fresh build shares nothing with older deployments | -| One `Resources` folder for all deployments | No | 718 MB | Version skew: 2 of the 7 builds would silently read the other branch's files | -| Hard links (`pax -rwl`) | No | 965 MB | Not smaller than snapshots, and writing one file in place changes it in every deployment. macOS's openrsync didn't link with `--link-dest` at all | -| Dropping idle worktrees' build directories | **Yes, in use** | 2.1 GB each | ccache rebuilds a cached revision in about a minute. Keep the worktree itself (see Pitfalls) | -| Sharing one `Packages` checkout between worktrees | **Only for the same resource set** | 0.8 to 1.1 GB each | Saves a copy where branches need the same resources; wrong for branches with their own (BDSP), see Pitfalls | - -## In use now - -`~/BDSPLab/bdsp_deploy.sh` stores `Resources` as snapshots in `builds/.resources//` and clones -the console-B copy; `prune_builds.sh` keeps the 5 newest deployments per build family (`bdsp-r105` -and `frlgnav8` are families `bdsp-r` and `frlgnav`) and deletes snapshots nothing links to. Result: -12 deployments take 587 MB (199 MB of it one shared snapshot) instead of 4.2 GB, and the three -worktree build directories in use take 6.4 GB. - -## Pitfalls found on 2026-10-29 - -- **A build's `Resources` come from its worktree's `Packages`.** Sharing one `Packages` checkout - between worktrees (a link) saves 0.8 to 1.1 GB each, but only where the branches need the same - resources. BDSP AutoStory needs its own set (1,467 files, with #1717's 789 AutoStory templates); - a worktree linked to upstream's set (686 files) built fine and then failed at run time with - "FileException: Unable to open file" on the first missing template. -- **`Resources` is copied once.** The copy is a post-build step that runs only when the build - directory has no `Resources` yet, so pointing a worktree at another `Packages` doesn't refresh - it: delete `/Resources` and rebuild, or copy it by hand. -- **Deployments aren't self-contained.** The app finds `onnxruntime` through an rpath into the - worktree it was built in. Deleting an idle worktree's build directory is safe; deleting the - worktree breaks every deployment built from it (dyld "Library not loaded"). -- **Look for links before deleting a folder.** Lab profiles linked their `DownloadedResources` to - one profile's copy; deleting that copy broke resource downloads in six profiles. - -## Lab output - -What the lab apps write grows faster than the builds and isn't covered above: -per-leg route screenshots and move screenshots from AutoStory runs (2.2 GB in -the console-B profile after two days), Command File Runner probe shots (1 GB, -cleared), and rotated logs. These are run evidence, not build output, so they -are cleared by hand after a run is recorded. - -Open questions: -- Should `Resources` hashing skip files the app writes at runtime, if any? -- Keep this in lab scripts only, or document it next to the ccache guide? -- Should AutoStory keep per-leg screenshots only for failed runs? +| One `Resources` folder for every deployment | A build silently reads another branch's files: 2 of the 7 builds tried would have | 718 MB | +| APFS clones for `Resources` across deployments | Every build re-copies `Resources`, so a clone from a fresh build shares nothing with older deployments | ~0 in the trial, a full tree (200-300 MB) per deploy in practice | +| Hard links (`pax -rwl`; macOS's openrsync ignores `--link-dest`) | No smaller than snapshots, and writing a file in place changes it in every deployment | 965 MB | +| Deleting a worktree that has deployments | The app loads `onnxruntime` through an rpath into the worktree it was built in; its deployments then crash at launch (dyld "Library not loaded") | — | +| Linking a worktree to a `Packages` checkout with another resource set | Builds fine, then fails at run time on the first missing file ("FileException: Unable to open file") | — | +| Deleting a folder without looking for links into it | Lab profiles linked `DownloadedResources` to one profile's copy; deleting it broke six profiles | — | + +After pointing a worktree at another `Packages`, delete `/Resources`: the build copies it +only when the folder is missing (a post-build step), so it won't refresh by itself. + +## Numbers + +| What | Size | +|---|---| +| Worktree build directory | 2.1 GB (1.0 GB objects, 0.9 GB `libSerialProgramsLib.a`, 0.2 GB `Resources`) | +| Lab deployment, plain copy | 334 MB (300 MB `Resources`, 30 MB `.app`) | +| `Resources` trees | BDSP 1,467 files, 300 MB; upstream 686 files, 199 MB | +| Shared ccache | about 1 GB; about 250 MB per fully rebuilt revision; capped at 5 GB | + +Scan of 2026-10-29 (85 GB free of 460 GB): + +| Item | Size | +|---|---| +| Lab deployments (16, with three snapshots) | 1.2 GB, 0.7 GB of it snapshots | +| Build directories in use (`bdsp/floaroma-mvp`, `frlg/brock-mvp`, `lab/frlg-nav-cfr`) | 6.4 GB | +| Other build directories (`bdsp/new-game-intro-v2`, `build/local-ccache`, `bbq/m8a`) | 6.2 GB | +| `Packages` checkouts (BDSP and upstream) | 1.8 GB | +| Qt 6.8.3 (debug symbols removed) | 1.6 GB | +| ccache | 0.9 GB | +| SerialPrograms profiles and logs | 4.8 GB |