Subversion svnsync vs. svnadmin dump/load: coordinating zero-downtime cutover without hybrid support

Question

Migration strategy integration boundarySubversion offers two primary migration paths: svnsync for incremental replication and svnadmin dump/load for full-history snapshots. Each tool addresses different constraints, but neither provides a built-in mechanism to combine their strengths for a true zero-downtime cutover.Core tensionsvnsync minimizes the final read-only window by replaying revisions incrementally, yet it requires the source repository to be quiesced during the last synchronization pass to guarantee consistency. svnadmin dump avoids incremental complexity but forces a maintenance window proportional to total repository size, which becomes impractical beyond several gigabytes. The tools operate independently — svnsync cannot resume from a dump-generated baseline, and svnadmin load cannot ingest an svnsync-mirrored repository without reinitialization.Unresolved coordinationHook scripts, authentication realms, unversioned root properties, and repository UUIDs all fall outside the replication scope of both approaches, requiring manual migration steps that introduce policy gaps during transition. Client working copies further complicate cutover because svn switch --relocate fails when UUIDs differ, forcing either UUID preservation via svnadmin setuuid or fresh checkouts.What criteria should determine whether the final svnsync read-only window or the full svnadmin dump window is the lesser operational risk for a given repository size and change rate? Are there documented patterns for staging a parallel svnsync target while a dump-based baseline is prepared, then reconciling the two without history corruption? How do teams validate that hook behavior and authentication realms are functionally equivalent on the target before directing live traffic?

Tasadduq Burney · Answer

Answer
The choice hinges on comparing two measurable windows:

Final svnsync sync window – the time to replay revisions that accumulated after the last incremental sync. It depends on current commit rate, network bandwidth, and I/O performance.
Full svnadmin dump/load window – the time to produce a dump of the entire repository and load it into the target. It scales linearly with total repository size and is independent of recent activity.

If the final svnsync window is shorter than the full dump/load window, svnsync alone offers the lower operational risk. Otherwise, a hybrid baseline with a recent dump followed by incremental sync is advisable.
Hybrid Cutover Pattern

Baseline load – Dump the source repository to a file (or use an incremental dump of a recent revision) and load it into a new target repository.
Configure svnsync – Point svnsync at the source and target, then run svnsync sync until the target catches up to the source’s current revision. Monitor the lag to estimate the final sync duration.
Read‑only window – Make the source read‑only (e.g., via a pre‑commit hook that rejects writes) and run a final svnsync sync to copy any revisions committed during the baseline load.
UUID alignment – If preserving existing working copies, run svnadmin setuuid on the target to match the source UUID.
Validation – Verify that hook scripts, authentication files, and repository properties are functionally equivalent on the target before redirecting clients.
Cutover – Point all clients to the target repository. If the UUID was changed, instruct users to run svn switch --relocate or perform fresh checkouts.

Hook & Authentication Validation Checklist

Export hooks directory and authz, passwd files from the source.
Deploy the same files to the target and run svnlook against a known transaction to compare exit codes and output.
Use svnserve or mod_authz_svn to test authentication and authorization rules against a representative user set.
Confirm repository properties (e.g., svn:author, svn:log) and the UUID match expectations.

Decision Criteria Summary

MetricImplication

Repository sizeLarge size → dump/load time dominates; small size → svnsync may win.
Commit rate (revs/h)High churn → final svnsync window grows; low churn → final svnsync window stays small.
Network & I/O throughputHigh throughput → both windows shrink; low throughput → final svnsync window may become the bottleneck.
Operational risk toleranceAcceptable brief read‑only period → svnsync; otherwise prefer hybrid baseline.

Missing Diagnostic Detail
To refine the recommendation, please provide:

The measured time to run svnadmin dump on a copy of the repository. 
The current average commit rate (revisions per hour) during peak activity.

Subversion svnsync vs. svnadmin dump/load: coordinating zero-downtime cutover without hybrid support

Migration strategy integration boundary

Core tension

Unresolved coordination

1 answer

Answer

Hybrid Cutover Pattern

Hook & Authentication Validation Checklist

Decision Criteria Summary

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments

Metric	Implication
Repository size	Large size → dump/load time dominates; small size → svnsync may win.
Commit rate (revs/h)	High churn → final svnsync window grows; low churn → final svnsync window stays small.
Network & I/O throughput	High throughput → both windows shrink; low throughput → final svnsync window may become the bottleneck.
Operational risk tolerance	Acceptable brief read‑only period → svnsync; otherwise prefer hybrid baseline.