Four files ship in mux-2.14.0.10.win32.src.zip that are refreshed from
nothing. Each was tracked once and deleted; each has ridden forward
from an ancestral reference tree ever since, because dowin32.sh starts
from the previous release and only the removed list can evict anything:
game/startmux.wsf deleted 12794cfe0
src/timer.cpp deleted 4ff1398de -> modules/engine/timer.cpp
src/tools/announce.c deleted 4ff1398de -> announce/announce.c
src/modules/sqlproxy.vcproj deleted 3c27ee9fe (VS2008 -> VS2013)
Dead weight rather than defects: the audit of the rebuilt 2.14.0.10
artifacts finds 213 .vcxproj references with 0 missing, so the
distribution builds with these present. This is cleanup for the next
cycle, not a reason to re-cut a signed release.
src/timer.cpp needed care. engine.vcxproj does reference "timer.cpp",
but bare, resolving to modules/engine/timer.cpp beside it; nothing
references the src/ copy. Removing the wrong one of two same-named
files would have broken the Windows build in precisely the way this
series of changes exists to prevent.
This is a re-do. a425da7ff carried the same four, but was pushed to
fix/release-toc-missing-sources after #1967 had already merged, so it
landed on a branch nobody was watching and never reached master -- no
error, no conflict, no notification, the work simply did not exist.
Re-cut from current master so it sits on top of #1968's preflight.
Checked against that preflight before pushing, rather than only that
the entries are present -- which is the check that missed the blank
line in ac6c24fef:
removed n (patchable u unpatched) = 0 conflicts
everything listed to ship exists = 0 missing
blank lines / CR / trailing newline = 0 / 0 / present
empty elements mapfile -t would see = 0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
d26f7f69d1