I'm just about wrapped up on a project where I was using a commercial SVN provider to store the source code. The web host the customer ultimately picked includes a repository as part of the hosting package, so, now that the project is over, I'd like to relocate the repository to their web host and discontinue the commercial account.
How would I go about doing this?
The tool to do that would be
svnadmin dump
But for this to work, you need filesystem-access to the repository. And once you have that (and provided the repository is in FSFS format), you can just copy the repository to its new location (if it's in BDB format, dump/load is strongly recommended).
If you do not have filesystem access, you would have to ask your repository provider to provide the dump for you (and make them delete their repository - and hope they comply)
You might find some help on migrating svn repositories here: Migrating a repository
This approach requires access to svnadmin.
If you want to move the repository and keep history, you'll probably need filesystem access on both hosts. The simplest solution, if your backend is FSFS (the default on recent versions), is to make a filesystem copy of the entire repository folder.
If you have a Berkley DB backend, if you're not sure of what your backend is, or if you're changing SVN version numbers, you're going to want to use svnadmin to dump your old repository and load it into your new repository. Using svnadmin dump will give you a single file backup that you can copy to the new system. Then you can create the new (empty) repository and use svnadmin load, which will essentially replay all the commits along with its metadata (author, timestamp, etc).
You can read more about the dump/load process here:
http://svnbook.red-bean.com/en/1.1/ch05s03.html#svn-ch-5-sect-3.5
Also, if you do svnadmin load, make sure you use the --force-uuid option, or otherwise people are going to have problems switching to the new repository. Subversion uses a UUID to identify the repository internally, and it won't let you switch a working copy to a different repository.
If you don't have filesystem access, there may be other third party options out there (or you can write something) to help you migrate: essentially you'd have to use the svn log to replay each revision on the new repository, and then fix up the metadata afterwards. You'll need the pre-revprop-change and post-revprop-change hook scripts in place to do this, which sort of assumes filesystem access, so YMMV. Or, if you don't want to keep the history, you can use your working copy to import into the new repository. But hopefully this isn't the case.
You can also use "hotcopy".
svn hotcopy OLD_REPOS_PATH NEW_REPOS_PATH
It takes full backup from repository, including all hooks, configuration files, etc..
Excerpt from my Blog-Note-to-myself
Now you can import a dump file e.g. if you are migrating between machines / subversion versions. e.g. if I had created a dump file from the source repository and load it into the new repository as shown below.
CmdShell> svnadmin dump D:\CoderZone2\svn-repos > ReposDump.dmp
CmdShell> svnadmin load D:\CoderZone\svn-repos < ReposDump.dmp
You can also use svnsync. This only requires read-only access on the source repository
If you do not have file access to the repository, I prefer this to make the dump file: rsvndump - remote Subversion repository dump http://rsvndump.sourceforge.net/