Question
Which Subversion migration approach preserves working copies best: svnsync mirror or hotcopy plus incremental dump?
Cig Finch
0 reputation · 05 Nov 2022, 08:23 UTC
views
Loading…
0 reputation · 05 Nov 2022, 08:23 UTC
I'm planning to move a small Subversion repository (a few thousand revisions, under 10 GB) to a new host while keeping the current server available for commits. Two documented approaches seem viable: maintaining a read-only mirror with svnsync and promoting it after a final sync, or taking an svnadmin hotcopy, loading it on the target, and applying an incremental dump of revisions committed during the load.
Two decision points are unclear to me. First, the repository UUID: keeping the original UUID should let existing working copies survive the switch with only a relocate, but I worry about both servers being reachable at once during cutover. Generating a new UUID seems safer but forces every working copy to be updated.
Second, svnsync does not appear to replicate lock state, so any locks held at the moment of the final sync would be lost on the target. I also need to confirm hook scripts must be copied manually in either approach.
Which method is more reliable for a zero-downtime cutover of a small repository? Should the UUID be preserved or regenerated when both hosts may briefly be online? How are outstanding locks typically handled at the final sync?
29775 reputation · 05 Nov 2022, 20:21 UTC
For a small repository (a few thousand revisions, <10 GB) that must stay online for commits during the move, the hotcopy + incremental‑dump approach is the safer option if you want existing working copies to survive with only a svn relocate. It preserves the original UUID, retains any locks that existed at the moment of the hotcopy, and keeps hook scripts in a single manual step. svnsync gives a zero‑downtime mirror but drops lock state and also requires you to copy hooks yourself.
subversionsvn relocate; a new UUID forces a full checkout or svn switch --relocate on every client.svnsync never copies locks; any lock held at the final sync is lost. A hotcopy captures the lock table as of the copy time; locks created after that point must be re‑applied manually.hooks automatically; copy the directory yourself on the target.svnsync can run while the source stays online, but you lose lock state.Hotcopy the source – on the current server run:svnadmin hotcopy /srv/svn/oldrepo /tmp/oldrepo_copy
Copy the hotcopy to the new host (e.g., scp -r /tmp/oldrepo_copy user@newhost:/srv/svn/).
Load the repository on the target – if the target is empty, move the directory; otherwise run:svnadmin load /srv/svn/newrepo < /tmp/oldrepo_copy/repo.dump
Copy hooks – scp -r /srv/svn/oldrepo/hooks user@newhost:/srv/svn/newrepo/hooks.
Generate incremental dump for new revisions – while the source remains online, identify the last revision in the hotcopy (e.g., svnlook youngest /srv/svn/oldrepo gives 1234) and run:svnadmin dump /srv/svn/oldrepo -r 1235:HEAD --incremental > /tmp/extra.dump
Load the incremental dump on the target:svnadmin load /srv/svn/newrepo < /tmp/extra.dump
Re‑apply new locks (if any) – if you cannot pause commits before the final dump, re‑apply any locks that were created after the hotcopy using svn lock or a script that reads the lock table from the source.
Switch clients – clients can svn relocate http://oldhost/svn/oldrepo http://newhost/svn/newrepo to keep the same UUID. No re‑checkout is needed.
Set up svnsync on the new host: svnsync init http://newhost/svn/newrepo http://oldhost/svn/oldrepo, then svnsync sync http://oldhost/svn/oldrepo until the repository is fully mirrored.
Before the final sync, stop new commits or be ready to re‑apply locks.
After the final sync, copy the hooks directory manually.
Clients use svn relocate as above.
Do you have any long‑lived locks that must remain intact across the migration? If so, the hotcopy method may be preferable unless you can re‑apply those locks manually after the cutover.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.