RenameFiles walks renameMap one entry at a time. Every rename is a round trip,
and on an S3 backend RenameFile is a CopyObject followed by a DeleteObject, so
a publish that rewrites a dozen indexes spends most of its wall clock waiting
on them in sequence.
Bounded at four in flight, matching the default used for concurrent package
uploads. The first error is returned rather than the last, and the remaining
renames still run, so a failure does not leave part of the set staged behind a
half-finished switch.
Measured against MinIO behind a proxy adding 50ms each way, publishing a
repository whose Contents is dominated by one package carrying 19,500 files:
publish update drops from 2703ms to 1624ms median, n=5 either side, a 40% cut.
The published object set and its sizes are identical before and after.
RenameFiles had no test coverage. It has four cases now: every entry renamed,
the concurrency limit respected, a failure reported without abandoning the
rest, and an empty rename map.
Martin Simon
c531cac535