One of the nice things about SVN is how easy it is to carry the complete SVN history from one server to another: “svnadmin dump” produces a single (large) dump file with the complete history, then “svnadmin load” to recreate it on the new machine. However, for a handful of our projects we have an SVN repository hosted on a machine where we don’t have shell access to run svnadmin.
After considerable Google searching, I found that SVN itself offers no way to do this; svnadmin takes these parameters:
svnadmin dump path-to-repos
and only works on local repositories. I found some mailing list discussion about it, but unfortunately it was of this form:
user: “I’d like to do X”
developer: “You don’t need to do X, it works like Y”
apt-get install svk (if you don’t have SVK yet)
rm -rf ~/.svk (if you have SVK, but don’t care about your current stuff)
mv ~/.svk ~/old.svk (if you have SVK, get your current config out of the way)
svk ls https://your.svn.URL/here/
svk will prompt you for all the bits of info needed to mirror the SVN repository to your local SVK storage, then list the top level files/directories. Next, take advantage of the fact that SVK uses SVN’s underlying storage mechanism, and dump that local SVK mirror, skipping revision 1 which contains SVK metadata:
svnadmin dump -r2:HEAD ~/.svk/local >something.dump
This dump can now be restored elsewhere with “svnadmin load”. Unfortunately the pathnames in it will be mangled, with the original SVN repository hostname and path prepended. For my purposes, this didn’t matter, as I only needed to make it available for occasional reference. You could of course use “svn mv” to clean it up.
On a broader note, SVK looks like a very fine distributed source control tool. On a single developer project I recently droppen SVN in favor of bzr, a distributed source control tool; one of these days I will choose such a tool for a larger project.
Update: I discuss another method for remote SVN backups, svnsync in a later post.