Limits of svnadmin recover after an interrupted repository format upgrade

When a Subversion repository format upgrade (svnadmin upgrade) is interrupted—by power loss, kill signal, or other failure—the repository may be left in an inconsistent state where the new format has been partially applied.

The documented safe recovery path relies on a pre‑upgrade svnadmin hotcopy backup, but in environments where taking such a backup is impractical or was omitted, it is unclear whether svnadmin recover or any other svnadmin operation can restore consistency without a backup, or whether the only viable option is to dump the repository up to the last good revision and load it into a fresh filesystem.

• What specific repository inconsistencies can svnadmin recover repair after an interrupted svnadmin upgrade, and which format‑step changes are beyond its capability?
• If svnadmin recover cannot fix the state, is there any supported procedure short of a full dump/load that can bring the repository back to a usable state?
• Are there any version‑specific guarantees (e.g., for FSFS formats after 1.8) that make an interrupted upgrade less likely to leave the repository unrecoverable without a backup?