Which Subversion migration approach preserves working copies best: svnsync mirror or hotcopy plus incremental dump?
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?