Even if the machines are on different operating systems, this is dead easy. On the source machine, simply ‘dump’ the repository:
svnadmin dump /path/to/repo > reponame.dump
tar zcf reponame.tgz reponame.dump
scp reponame.tgz hostname:/path/to/new/repo
tar zcf reponame.tgz reponame.dump
scp reponame.tgz hostname:/path/to/new/repo
Then login to the new machine, and set up the new repo:
cd /path/to/new
svnadmin create reponame
tar zxf reponame.tgz
svnadmin load reponame < reponame.dump
svnadmin create reponame
tar zxf reponame.tgz
svnadmin load reponame < reponame.dump
That’s all there is to it. Then you can of course delete the dump files, the .tgz files, and even the source repo if you are brave.
Popularity: 97%
May 13th, 2005 at 8:49 am
Thanks for the tip, I’m moving SVN from my local development machine to a company development server.
August 12th, 2005 at 4:51 pm
Very concise and clear!
Although you could mention that working-directories that are checked out need to be modified. (svn switch does not yet support different reposositories). Either deleted and then checked out again, or having all folders’ “entries” file modified to suit the new repository url. Not 100% if this last tip works or of it was something I did and did not work… Hmm, at least I managed to move from my local computer to company dev-server without the need to check-out all again.
Of, course, if the working-copy is of small size, it is by much easier to delete and check-out again.
August 13th, 2005 at 10:11 am
Fredrik,
You are correct. I had just not touched on that point, as I was testing a new checkout, and knew that svn switch would not work for me.
September 21st, 2005 at 4:47 pm
what is tar zcf and tar zxf? Is it some sort of command? My manuals contain no such command.
November 22nd, 2005 at 4:40 am
tar is a compression tool, found on *nix OSes, a bit like winzip.
You could use winzip to zip and unzip the dump if you wanted. You don’t even have to compress it if it’s small, or you don’t mind the waiting.
And scp is a means of copying files between machines running SSH. You could use the windows explorer, email it, whatever. The important commands are the svnadmin dump & svnadmin load.
December 4th, 2005 at 3:52 am
Is there an efficient way to move a whole collection of (native filesystem) repositories at once? I use it for managing my writing projects, so that old OK stuff doesn’t get fatally overwritten by corrupt new stuff, and have been putting each project into its own repository. dump/load sounds rather cumbersome, and naively writing the repositories to CD seems to produce errors; empirically, I’ve found that pkzipped archives with file times preserved seem to work, but I don’t trust it.
January 9th, 2006 at 10:16 am
does this move user accounts also?
January 10th, 2006 at 12:25 am
moshe,
I don’t believe users for authentication move, no. This would just be the revision history.
March 10th, 2006 at 11:40 am
Since you just pack up one file (reponame.dump), why not just use “gzip”? As in
gzip –best reponame.dump
Then scp reponame.dump.gz and so on. Unpacking is done by gunzip reponame.dump
April 11th, 2006 at 3:32 am
Is it possible to move a repository with user commands? I do not have svnadmin (shell) access to the new repository.
Also would it be possible to use the –deltas option to make dump smaller?
“By default, the dump file will be quite large—much larger than the repository itself. That’s because every version of every file is expressed as a full text in the dump file. This is the fastest and simplest behavior, and nice if you’re piping the dump data directly into some other process (such as a compression program, filtering program, or into a loading process). But if you’re creating a dump file for longer-term storage, you’ll likely want to save disk space by using the –deltas switch. With this option, successive revisions of files will be output as compressed, binary differences—just as file revisions are stored in a repository. This option is slower, but results in a dump file much closer in size to the original repository.” -SvnBook-ch-5-sect-3.1.2
-Pete
May 25th, 2006 at 7:18 am
I would reccomend that when loading that you use the command
svnadmin load –force-uuid reponame
June 16th, 2006 at 8:04 am
You can do the whole thing in a single line, if you trust your connection to not break and leave things in an inconsistent state
svnadmin dump [old_repository] | ssh -C [host] svnadmin load [new_repository]
June 16th, 2006 at 10:23 am
Shish, I knew someone would point out a one liner eventually
June 28th, 2006 at 3:26 am
great, this is a very useful tip
August 18th, 2006 at 11:04 am
Cool! Thanks a bunch. I’m pretty sure one can find the same info in the SVN docs, but have your advice at #1 in Google helps a lot
Cheers
October 19th, 2006 at 11:10 am
I have two repositories under svnDBs: svnDBs/r1 and svnDBs/r2, what’s wrong with scp’ing the entire svnDBs tree from one machine to another (i.e. without dump/load)?
October 24th, 2006 at 9:34 am
Joe,
If the machines are the same general setup (OS, CPU architecture), then I wouldn’t see an issue with just scp’ing everything.
November 10th, 2006 at 9:11 am
If you have a large repository, you might want to follow the tip at http://svn.haxx.se/users/archive-2006-09/1129.shtml, to speed import time.
November 15th, 2006 at 7:38 am
I love little tips like these. Thanks a lot.
November 20th, 2006 at 11:40 pm
[quote]
svnadmin dump [old_repository] | ssh -C [host] svnadmin load [new_repository]
[/quote]
does this one liner require both SVN’s to be the same version?
November 21st, 2006 at 11:54 pm
This tip was nice. But I have one question. How do i synchronize my checked out copy with the new location? Is that possible??
April 23rd, 2008 at 5:09 pm
Sweet, that was too easy.
April 24th, 2008 at 12:26 am
I need to disable the svn access in the old server after the repository move, so that we do not accidentally lose any changes due to developers checking into the old repository.
Is there any way for this??
May 13th, 2008 at 2:04 pm
Thanks for this! You saved me a whole lot of work!