Summary of the method of the SVN repository migration consolidation

Sometimes need to migrate from one machine SVN repository to another machine, if the amount of data is very large, there is no good method is very inconvenient, in fact, the migration of SVN is similar to the migration of MySQL, there are export import scenarios

Here's what subversion officially recommends for backup.
Close all running processes and verify that no programs are accessing the repository (such as httpd, Svnserve, or local users in direct access).
Backing up the SVN repository
#压缩备份
Svnadmin Dump/data/svn/repository | gzip >/tmp/repository-backup.gz
#不压缩备份
Svnadmin dump/data/svn/repository >/TMP/REPOSITORY-BACKUP.SVN

Recovering the SVN repository
#建立新的svn存储库
Svnadmin create/home/workhome/svn/newrepository
#确认成功与否
Ls-l/home/workhome/svn/newrepository
#导入存储库数据
Svnadmin Load/home/workhome/svn/newrepository </TMP/REPOSITORY-BACKUP.SVN

SVN database Migration Method One

Known as SVN full-Library operation, or SVN global backup and recovery, repository data porting: Svnadmin dump, svnadmin load
Export:
$svnadmin dump repos > DumpFile//Export the specified repository to a file dumpfile
New:
$svnadmin Create Newrepos
Import:
$svnadmin Load Newrepos < DumpFile

SVN Database Migration method two
Incremental or batch backup, batch recovery, specific reversion export:
$svnadmin dump Repos–r >rev-23.dumpfile//Export version23
$svnadmin dump Repos–r 100:200 >rev-100-200.dumpfile//Export version100~200
Batch export: Larger libraries can be batch-exported for easy backup
$svnadmin Dump Repos–r 0:1000 >0-1000.dumpfile
$svnadmin dump Repos–r 1001:2000--incremental >1001-2000.dumpfile
$svnadmin dump Repos–r 2001:3000--incremental >2001:3000.dumpfile
Batch import to load these backup files into a new repository
$svnadmin Load Newrepos < 0-1000.dumpfile
$svnadmin Load Newrepos < 1001-2000.dumpfile
$svnadmin Load Newrepos < 2001:3000.dumpfile

SVN Database Migration method Three
After exporting, do the library sorting or other sorting operations on the import to filter the Repository history:
Suppose you have a repository with three items: Calc,calendar, and spreadsheet. They are laid out in the repository as follows:
/
calc/
trunk/
branches/
tags/
calendar/
trunk/
branches/
tags/
spreadsheet/
trunk/
branches/
tags/
Now it's time to move these three projects to three separate repositories. First, dump the entire repository:
$ svnadmin dump/path/to/repos > Repos-dumpfile
* Dumped Revision 0.
* Dumped Revision 1.
* Dumped Revision 2.
* Dumped Revision 3.
Then, three times the dump file is fed into the filter, and each time you keep only one top-level directory, you can get three dump files:
$ Cat Repos-dumpfile | Svndumpfilter include calc > calc-dumpfile
$ Cat Repos-dumpfile | Svndumpfilter include calendar > Cal-dumpfile
$ Cat Repos-dumpfile | Svndumpfilter include spreadsheet > Ss-dumpfile
Now you have to make a decision. Each of these three dump files can be used to create an available repository, but they retain the exact path structure of the original repository. That is, although Project Calc now has an exclusive repository, the repository also retains a top-level directory called Calc. If you want trunk, tags, and branches to be located directly under the root path of the repository, you may need to edit the dump file, adjust the Node-path and Copyfrom-path header parameters, and delete the path calc/. Also, you want to delete the part of the dump data that created the Calc catalog. In general, here are some of the following:
Node-path:calc
Node-action:add
Node-kind:dir
content-length:0
Warning:
If you plan to remove a top-level directory by manually editing the dump file, be careful not to have your editor convert the newline character to a local format (such as \ r \ n). Otherwise the contents of the file do not match the desired format, and the dump file is invalidated.
The rest of the work is to create three new repositories, and then import the three dump files separately:
$ svnadmin Create calc; Svnadmin Load Calc < calc-dumpfile
$ svnadmin Create calendar; Svnadmin Load Calendar < Cal-dumpfile
$ svnadmin Create spreadsheet; Svnadmin Load Spreadsheet < Ss-dumpfile
The two subcommands of Svndumpfilter can be set by the option to handle "empty" revisions. If a specified revision contains only changes to the path, the filter removes it because the currently empty revision is often useless or even annoying. To give users the option to process these revisions, Svndumpfilter provides the following command-line options:
--drop-empty-revs
Do not generate any empty revisions, ignoring them.
--renumber-revs
If an empty revision is excluded (by using the--drop-empty-revs option), modify the numbering of the other revisions to make sure that the numbering sequence is sequential.
--preserve-revprops
If an empty revision is retained, keep these empty revisions of the properties (log information, author, date, custom attributes, and so on). If this option is not set, an empty revision retains only the initial timestamp and an automatically generated log message indicating that the revision was processed by Svndumpfilter.
Although Svndumpfilter is very useful and can save a lot of time, it is a double-edged sword. First, this tool is extremely sensitive to path semantics. Double-check that the path in the dump file is preceded by a slash. Perhaps Node-path and Copyfrom-path these two head parameters to help you a little.
Node-path:spreadsheet/makefile
If these paths start with a slash, then the paths you pass to Svndumpfilter include and Svndumpfilter exclude must also start with a slash (and vice versa). If, for some reason, the paths in the dump file are not uniformly used or do not start with a slash, you may need to fix these paths, using either a diagonal line or a slash start.
In addition, the path generated by the copy operation can cause trouble. Subversion supports copy operations in the repository, that is, copying an existing path and generating a new one. The problem is that a file or directory that svndumpfilter retains may be copied from a file or directory that is excluded by a svndumpfilter. That is, in order to ensure the integrity of the dump data, Svndumpfilter needs to sever the relationship between the files that are copied from the excluded path and the source files, and add the contents of those files to the dump data in a new way. However, because the Subversion repository dump file format contains only the revision information, the contents of the source file are largely inaccessible. If you are unsure whether a similar situation exists in the repository, it is a good idea to reconsider which paths to keep/exclude.
Backup Environment Note points:
1. Make sure no other processes access the repository, close Apache, Svnserve services
2. Become an administrator of the repository, if you restore the repository as a different identity, you may change the access rights of the repository file, resulting in the inability to access after recovery
3, Svnadmin Recover/path/to/repos
4. Restart the service process
SVN Database Collation method
Do not go through the dump,load operation, the implementation of the SVN database, first design the adjusted directory, and then open the repository, select the file (folder) to adjust or transfer, and right-drag, do not let go and then the file (folder) will be transferred to the destination folder-- >--select Move items to here--> complete

With each such adjustment, everyone will worry about whether the history will still exist, TORTOISESVN will not be displayed by default, and an option needs to be removed.

This allows for library-based tuning operations, but everything is not as good as it should be, and revision will grow a lot when this happens.
My idea is:
Stop the current SVN service, the current SVN library directly to organize, just like the folder stored in the computer, and then open the SVN service, instantly display the adjusted effect, haha. is not a bit whimsical, in fact, I also think this is not possible, unless the use of tools to access, otherwise the SVN library is not visible, I hope that later what configuration management tool can let administrators have such permissions.

Experiment:
one, in the move out server execution:
[email protected]:~/csvn/bin> CSVN Stop
Stopping Csvn Console ...
Waiting for CSVN Console to exit ...
Waiting for CSVN Console to exit ...
Stopped csvn Console.
[email protected]:~/csvn/bin> csvn-httpd Stop
Stopping Subversion Edge Apache Server: Done
[email protected]:~/csvn/data/repositories> Svnadmin Dump/home/svn/csvn/data/repositories/camp | Gzip >camp_dumpfile_20130610.gz
......
* Dumped revision 4495.
* Dumped revision 4496.
[email protected]:~/csvn/data/repositories> ls
Camp camp_dumpfile_20130610.gz cpst CSVN csvn-httpd docm

second, in the migration server execution:
Take out the exported files on the server camp_dumpfile_20130610.gz;
[email protected]:~/data/repositories> Svnadmin Create/home/csvn/data/repositories/newcamp
[email protected]:~/data/repositories> gzip-d camp_dumpfile_20130610.gz
[email protected]:~/data/repositories> Svnadmin Load/home/csvn/data/repositories/newcamp < camp_dumpfile_20130610
......
<<< Started new transaction, based on original revision 4495
* Editing path:trunk/site/campost/src/dsp/frmdomitemmod.mcpp ... done.
* Editing path:trunk/site/campost/src/dsp/frmintitemmod.mcpp ... done.
-------Committed Revision 4495 >>>
<<< Started new transaction, based on original revision 4496
* Editing path:trunk/site/campost/src/dsp/frmdspinterclosedisp.mcpp ... done.
-------Committed Revision 4496 >>>
[email protected]:~/bin> CSVN Start
Starting CSVN Console ...
CSVN Console started
Waiting for application to initialize (this could take a minute) ..... ..... ..... ..... ......... ...............
CSVN Console is ready at HTTP://LOCALHOST:3343/CSVN
[email protected]:~/bin> csvn-httpd Start
Starting Subversion Edge Apache Server:

This article is reproduced from http://blog.chinaunix.net/uid-354915-id-3766906.html

Summary of the method of the SVN repository migration consolidation