As a dev team we’ve used SubVersion reliably for many years. The ability to concurrently access files was a big step up from the bad old days of having exclusively locked files in Visual SourceSafe (shudder).
Now it’s the end of an era and we’re starting to migrate to Git – this includes following the best practice of moving the files but leaving the commit history behind (a “tip migration”). Consequently we’ve chosen to hang on to our SubVersion repositories for at least the next 12 months – just in case we need to refer back to older versions of files, or branches left behind.
As part of this preservation we are consolidating our SubVersion servers – in particular we need to move several large repos off a Windows Server 2003 machine.
The preferred method to backup and restore a SubVersion repo is to use the SvnAdmin Dump and Load commands.
We could dump an entire repo in one go, like so:
svnadmin.exe dump MyRepoName > X:\Dumps\MyRepoName.dump
This works fine for all repos but dump files can be very large, they contain every version of every file ever committed. The biggest dump ended up being over 100GB – and failed to load on the destination server. It ran out of memory, oh dear!
To make things more manageable we’re using a couple of switches on the dump command. The r switch allows us to specify which revisions we want in each dump file. We’ve chosen to break repos into dump files containing 200 revisions each. The incremental switch tells svnadmin not to baseline the dump with previous files and just to include the deltas for the revisions stated. Like so:
svnadmin.exe dump MyRepoName –r0:199 --incremental > X:\Dumps\ MyRepoName0-199Revs.dump
With our repos broken into bite-sized chunks we can start loading them up on the new server, like this:
svnadmin.exe load --force-uuid MyRepoName < X:\Dumps\ MyRepoName0-199Revs.dump
The force-uuid switch is important, it keeps the ID of the repo the same. This means that users who have the repo checked out from the old server can easily repoint to the new server, using the TortoiseSVN > Relocate command.
OK – so it’s a bit of work to break the repos up and reassemble them. I recommend generating the command statements (I used Excel) and executing them with a batch file (don’t use PowerShell – it can corrupt your dump files).
Happy migrating!
Now it’s the end of an era and we’re starting to migrate to Git – this includes following the best practice of moving the files but leaving the commit history behind (a “tip migration”). Consequently we’ve chosen to hang on to our SubVersion repositories for at least the next 12 months – just in case we need to refer back to older versions of files, or branches left behind.
As part of this preservation we are consolidating our SubVersion servers – in particular we need to move several large repos off a Windows Server 2003 machine.
The preferred method to backup and restore a SubVersion repo is to use the SvnAdmin Dump and Load commands.
We could dump an entire repo in one go, like so:
svnadmin.exe dump MyRepoName > X:\Dumps\MyRepoName.dump
This works fine for all repos but dump files can be very large, they contain every version of every file ever committed. The biggest dump ended up being over 100GB – and failed to load on the destination server. It ran out of memory, oh dear!
To make things more manageable we’re using a couple of switches on the dump command. The r switch allows us to specify which revisions we want in each dump file. We’ve chosen to break repos into dump files containing 200 revisions each. The incremental switch tells svnadmin not to baseline the dump with previous files and just to include the deltas for the revisions stated. Like so:
svnadmin.exe dump MyRepoName –r0:199 --incremental > X:\Dumps\ MyRepoName0-199Revs.dump
With our repos broken into bite-sized chunks we can start loading them up on the new server, like this:
svnadmin.exe load --force-uuid MyRepoName < X:\Dumps\ MyRepoName0-199Revs.dump
The force-uuid switch is important, it keeps the ID of the repo the same. This means that users who have the repo checked out from the old server can easily repoint to the new server, using the TortoiseSVN > Relocate command.
OK – so it’s a bit of work to break the repos up and reassemble them. I recommend generating the command statements (I used Excel) and executing them with a batch file (don’t use PowerShell – it can corrupt your dump files).
Happy migrating!
Comments
Post a Comment