svnadmin dump/load restore limits for hooks and config verification

Answer the exact question first

What does svnadmin verify guarantee? It only checks that the internal SQLite/FSDB files of a repository are internally consistent. It does not compare the repository’s revisions against any source or dump file, so it cannot assure that the restored content matches the original.

What happens to the UUID when loading into a fresh repository? The UUID stored in the dump stream becomes the UUID of the new repository. If the target repository already has a UUID that differs, svnadmin load aborts with a UUID‑mismatch error.

Are hooks, svnserve.conf, and authz included in the dump? No. The dump stream contains only revision data and the repository’s internal configuration (e.g., revision properties). All files in the conf directory—including hooks, svnserve.conf, authz, and passwd—must be copied manually after the load.

Likely explanation

Subversion’s design separates “data” from “configuration.” The dump/load tools were created to move versioned history, not operational settings. The UUID is part of the history metadata, so it is preserved automatically. Hooks and authz are considered repository‑level policy rather than data, so they’re excluded by design.

Confirmed facts

• svnadmin verify performs only internal consistency checks.
• When loading into an empty repository, the UUID in the dump becomes the new repository’s UUID.
• Hooks, svnserve.conf, authz, and other conf files are not part of the dump stream.

Practical steps for a full restore

1. Dump the source repository:

   svnadmin dump /path/to/source-repo > repo.dump

2. Create a new empty repository:

   svnadmin create /path/to/target-repo

3. Load the dump into the target:

   svnadmin load /path/to/target-repo < repo.dump

4. Verify internal consistency:

   svnadmin verify /path/to/target-repo

5. Confirm content equivalence (optional but recommended):**
   • Check revision counts:

     svnlook youngest /path/to/target-repo
     svnlook youngest /path/to/source-repo

   • Compare a few revision logs:

     svnlook log /path/to/target-repo -r 1:10
     svnlook log /path/to/source-repo -r 1:10

   • Diff a sample file in a specific revision:

     svnlook diff /path/to/target-repo -r 5 /path/to/file
     svnlook diff /path/to/source-repo -r 5 /path/to/file

6. Copy configuration manually:

   cp -r /path/to/source-repo/conf/* /path/to/target-repo/conf/
   # Ensure file permissions are preserved if required
   chmod -R 750 /path/to/target-repo/conf
   

7. Test access controls and hooks: Run a few commit or checkout operations against the target repository to confirm that authz and hooks behave as expected.

Missing diagnostic detail that could change the recommendation

Does the target repository already contain data or a non‑matching UUID? If it isn’t empty, you’ll need to either delete its contents first or use svnadmin load --force-uuid (available in newer Subversion releases) to override the UUID, but this is rarely recommended for production restores.