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

Migration strategy integration boundary

Subversion 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 tension

svnsync 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 coordination

Hook 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?