Here are three ways to create a full mirror of a Subversion repository:
- Treat the repository like any other filesystem and recursively copy it to the mirror location.
- Use svnadmin dump and svnadmin load.
- Use svnadmin hotcopy.
There are important differences between these three strategies.
You can of course:
cp -R PATH_TO_REPOS PATH_TO_MIRROR
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
2345 has been chosen as a suitable port for the data transfer.
Perhaps the most obvious way to mirror a Subversion repository is to
svnadmin dump with
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.
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.
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.
svnadmin hotcopy PATH_TO_REPOS PATH_TO_MIRROR
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.
Svnadmin provides another option,
svnadmin verify to check a
repository. This basically iterates through all revisions in the
repository by internally dumping all revisions and discarding the
output — so it takes a while.
svnadmin verify PATH_TO_MIRROR
Software developers don’t feel secure unless their source repository is safely backed up – or at least they shouldn’t – and they are reluctant to suffer repository downtime or excessive maintenance overheads. Live Subversion repositories can be mirrored quickly and safely using a simple command. With a little extra effort, this command can be scheduled to run automatically, every week, say.
As a next step, by using the Subversion post-commit hook every check-in to the repository can instantly and incrementally be copied to the repository mirror. I’ll provide details of how to do this in my next post.
For more information see:
Nice job on this, it was exactly what I was looking for.
Thanks for the feedback. I wonder, though, if some of the advice in this post has grown out of date. Subversion 1.4 adds a new tool "svnsync" which is designed to help mirror Subversion repositories. (Unfortunately I can't report directly on this tool since I haven't had a chance to try it.) Everything in this post remains true, though, and if you're on 1.3 or earlier, these are your options. http://subversion.tigris.org/svn_1.4_releasenotes.html
May be this question is already answered. But I was still unsure. I have setup a local svn mirror which syncs to the svn server installed elsewhere. Right now the setup is readonly and one way. Is there a way by which I can commit changes to the mirror and then this change is reflected in the master repo?
Um. Sorry, I don't know the answer to this one. I'd suggest asking the question on the subversion users mailing list:
Hi, have found a workaround for a two way mirror(Which is the only posiiblity with svn rite now apart from svk). have to commit to the master repo after doing a repo switch using svn switch --relocate and switch back to local mirror for updates and chekouts.
have blogged it on http://ajopaul.wordpress.com
I'm trying to replicate a repository using
Is it oK once I created the to compress it, tar, gzip, and do some kind of remote copy to another system, scp, rcp, ftp ?
Uncompress it and bring up the repository?
Jeff, you can get a definitive answer either by reading the documentation or from the subversion users mailing list.
I've never had any trouble, and I don't think you will, so long as you take the usual precautions (e.g. don't use text mode for ftp transfer). I'd also be careful with file permissions and I'd advise running a sanity check on your replicated repository.
My aim is to mirror a branch (frozen) of a repository in one VPN into another repository in an other VPN.
My idea was to check it out from the original and committing to the other.
As I'm really new to SVN and I haven't read the whole book yet, maybe someone here can give me a hint whether or not this is possible and if so, where to read.
Skeeve, I don't think checking out and committing is the way to go. I'd look into svndumpfilter. If your original repository is a large one, you might like to create something smaller to experiment on. As ever, try the subversion users mailing list if you need more help.
Is there any chance of a single-step svnadmin way to mirror a repos on one machine to another, or is the only way to go dumping and tranferring via other means?
Rick, the svn administrative tools are file-system based, and will work happily across (e.g) NFS mounts. You just have to be a little careful with user and group ids. If it's a small repository,
svnadmin hotcopygets the job done quickly. For incremental maintenance of a mirror on a second machine, I'd look into
svnsync-- which looks to be like
rsyncfor Subversion repositories.