Subversion Rollback After svnadmin Upgrade: Can We Safely Revert to a Prior Repository Format?

Direct answer

There is no supported way to "roll back" an upgraded FSFS repository to its previous format while keeping the revisions that were committed after the upgrade. The svnadmin upgrade operation is irreversible at the filesystem level.

Confirmed facts

• The upgrade changes the on‑disk FSFS layout to a newer version that older Subversion binaries cannot read.
• Subversion documentation explicitly states that upgrades are one‑way; there is no svnadmin downgrade command.
• A repository dump (svnadmin dump) is format‑independent and contains all revisions, properties, and log messages.
• Loading that dump into a newly created repository with an older FSFS version (svnadmin create --fs-type fsfs) preserves every revision, but the resulting repository will lack any FSFS‑specific features that depend on the newer format (e.g., sharded packing, certain rev‑prop optimizations).
• A hotcopy taken before the upgrade can be restored, but it will contain only the revisions that existed at the time of the hotcopy; any commits made after the upgrade will be lost.

Steps to retain all history while moving to an older FSFS format

1. Take a dump of the upgraded repository:

   svnadmin dump /path/to/upgraded/repo > repo_dump.svn

2. (Optional) Verify the dump is complete by checking the youngest revision number in the dump header or by running svnadmin verify on a temporary load.
3. Create a new repository with the desired older FSFS version:

   svnadmin create --fs-type fsfs /path/to/downgraded/repo

4. Load the dump into the new repository:

   svnadmin load /path/to/downgraded/repo < repo_dump.svn

5. After the load, run verification:

   svnadmin verify /path/to/downgraded/repo

6. Optionally compare the youngest revision of the source and target repositories to ensure no revisions were omitted.
7. If you need existing working copies to continue without re‑checking out, copy the original repository’s UUID into the new repo (svnadmin setuuid) before loading, or use the --ignore-uuid flag on load and then set the UUID to match the original.

When a hotcopy restore might be sufficient

If you can afford to lose the revisions made after the upgrade, simply restore the pre‑upgrade hotcopy. This is faster and requires less disk space, but it discards any post‑upgrade history.