Here are three ways to create a full mirror of a Subversion repository: 1. Treat the repository like any other filesystem and recursively copy it to the mirror location. 2. Use svnadmin dump and svnadmin load. 3. Use svnadmin hotcopy. There are important differences between these three strategies. Treating the Repository as a Filesystem You can of course:
This is a bad idea if the repository is in use – you’re copying a moving target – so you’ll have to take down the Subversion server while making the mirror. If you’re prepared to accept this downtime, netcat, nc, combined with tar is a neat way to recursively copy a directory across a network connection using TCP/IP.
# On the destination "mirror" machine
nc -l -p 2345 | tar xv
# On the source machine
tar c PATH_TO_REPOS > /dev/tcp/DOTTED.IP.OF.MIRROR/2345
Here, 2345 has been chosen as a suitable port for the data transfer. Using Svnadmin Dump and Load Perhaps the most obvious way to mirror a Subversion repository is to combine svnadmin dump with svadmin load.
svnadmin dump PATH_TO_REPOS | svnadmin load PATH_TO_MIRROR
Run on its own, svnadmin dump is designed to create a portable repository dump. The resulting dumpfile can be loaded into a new Subversion repository – even if the new repository is using a different database backend, or even a different revision of Subversion. Svnadmin dump will happily run on a live repository (no need to take the server down). In short, combining svnadmin dump with svnadmin load is probably more powerful than we need if we just want to mirror our repository to a new location. Svnadmin dump – on its own – is the best way to fully backup a repository, since the dumpfile it creates is portable (as described above). If we replicate a repository by piping svnadmin dump to svnadmin load, we lose the dumpfile in the pipeline and do far more work than we need to. Actually, it’s the computer which does the work – we just type a command and let it run. As a rough guideline, I have worked on a repository which occupies about 10Gb on disk, contains ~50K files and maybe a hundred branches. To dump and load this repository takes about 4 hours. A recursive copy completes in a few minutes. One more point: svnadmin dump does not dump your repository configuration files and hook scripts. If your backup strategy is based around these commands, you will need separate arrangements for backing up hook scripts and configuration files. Using Svnadmin Hotcopy The third option combines the best features of the previous two. Using svnadmin hotcopy doesn’t require any server downtime, completes in minutes, and replicates server configuration and hook scripts.
The command is disconcertingly silent – no indication of progress, no verbose option. As is usual in UNIX-world, however, no news is good news. I just ran: du -sh PATH_TO_REPOS PATH_TO_MIRROR to confirm the hotcopy was running and to check on its progress.

Leave a Reply

Your email address will not be published. Required fields are marked *