SVN库迁移整理总结
SVN数据库迁移方法一(SVN全库操作,或称SVN全局备份并恢复):
版本库数据的移植:svnadmin dump、svnadmin load
导出:
$svnadmindump repos > dumpfile //将指定的版本库导出成文件dumpfile
新建:
$svnadmin createnewrepos
导入:
$svnadmin load newrepos< dumpfile
SVN数据库迁移方法二(增量备份或批次备份,批次恢复)
特定reversion导出:
$svnadmindump repos –r 23>rev-23.dumpfile //将version23导出
$svnadmindump repos –r 100:200>rev-100-200.dumpfile //将version100~200导出
批次导出:对比较大的库可以批次导出，便于备份
$svnadmin dump repos –r0:1000 >0-1000.dumpfile
$svnadmin dump repos –r1001:2000 --incremental>1001-2000.dumpfile
$svnadmin dump repos –r2001:3000 --incremental>2001:3000.dumpfile
批次导入，将这几个备份文件装载到一个新的版本库中
$svnadmin load newrepos< 0-1000.dumpfile
$svnadmin load newrepos< 1001-2000.dumpfile
$svnadmin load newrepos< 2001:3000.dumpfile
SVN数据库迁移方法三(导出后,在导入时对库做分库整理或其它整理操作)
过滤版本库历史:
假设有一个包含三个项目的版本库：calc，calendar，和spreadsheet。它们在版本库中的布局如下：
/
calc/
trunk/
branches/
tags/
calendar/
trunk/
branches/
tags/
spreadsheet/
trunk/
branches/
tags/
现在要把这三个项目转移到三个独立的版本库中。首先，转储整个版本库：
$ svnadmin dump /path/to/repos > repos-dumpfile * Dumped revision 0. * Dumped revision 1. * Dumped revision 2. * Dumped revision 3. … $
然后，将转储文件三次送入过滤器，每次仅保留一个顶级目录，就可以得到三个转储文件：
$ cat repos-dumpfile | svndumpfilter include calc > calc-dumpfile … $ cat repos-dumpfile | svndumpfilter include calendar > cal-dumpfile … $ cat repos-dumpfile | svndumpfilter include spreadsheet > ss-dumpfile … $
现在你必须要作出一个决定了。这三个转储文件中，每个都可以用来创建一个可用的版本库，不过它们保留了原版本库的精确路径结构。也就是说，虽然项目calc现在独占了一个版本库，但版本库中还保留着名为calc的顶级目录。如果希望trunk、tags和branches这三个目录直接位于版本库的根路径下，你可能需要编辑转储文件，调整Node-path和Copyfrom-path头参数，将路径calc/删除。同时，你还要删除转储数据中创建calc目录的部分。一般来说，就是如下的一些内容：
Node-path: calc Node-action: add Node-kind: dir Content-length: 0 警告:
如果你打算通过手工编辑转储文件来移除一个顶级目录，注意不要让你的编辑器将换行符转换为本地格式（比如将\r\n转换为\n）。否则文件的内容就与所需的格式不相符，这个转储文件也就失效了。
剩下的工作就是创建三个新的版本库，然后将三个转储文件分别导入：
$ svnadmin create calc; svnadmin load calc < calc-dumpfile $ svnadmin create calendar; svnadmin load calendar < cal-dumpfile $ svnadmin create spreadsheet; svnadmin load spreadsheet < ss-dumpfile
svndumpfilter的两个子命令都可以通过选项设定如何处理“空”修订版本。如果某个指定的修订版本仅包含路径的更改，过滤器就会将它删除，因为当前为空的修订版本通常是无用的甚至是让人讨厌的。为了让用户有选择的处理这些修订版本，svndumpfilter提供了以下命令行选项：
-
--drop-empty-revs -
不生成任何空修订版本，忽略它们。
-
--renumber-revs -
如果空修订版本被剔除（通过使用
--drop-empty-revs选项），依次修改其它修订版本的编号，确保编号序列是连续的。 -
--preserve-revprops -
如果空修订版本被保留，保持这些空修订版本的属性（日志信息，作者，日期，自定义属性，等等）。如果不设定这个选项，空修订版本将仅保留初始时间戳，以及一个自动生成的日志信息，表明此修订版本由svndumpfilter处理过。
尽管svndumpfilter十分有用，能节省大量的时间，但它却是把不折不扣的双刃剑。首先，这个工具对路径语义极为敏感。仔细检查转储文件中的路径是不是以斜线开头。也许Node-path和Copyfrom-path这两个头参数对你有些帮助。
… Node-path: spreadsheet/Makefile …
如果这些路径以斜线开头，那么你传递给svndumpfilterinclude和svndumpfilterexclude的路径也必须以斜线开头（反之亦然）。如果因为某些原因转储文件中的路径没有统一使用或不使用斜线开头，也许需要修正这些路径，统一使用斜线开头或不使用斜线开头。
此外，复制操作生成的路径也会带来麻烦。Subversion支持在版本库中进行复制操作，也就是复制一个存在的路径，生成一个新的路径。问题是，svndumpfilter保留的某个文件或目录可能是由某个svndumpfilter排除的文件或目录复制而来的。也就是说，为了确保转储数据的完整性，svndumpfilter需要切断这些复制自被排除路径的文件与源文件的关系，还要将这些文件的内容以新建的方式添加到转储数据中。但是由于Subversion版本库转储文件格式中仅包含了修订版本的更改信息，因此源文件的内容基本上无法获得。如果你不能确定版本库中是否存在类似的情况，最好重新考虑一下到底保留/排除哪些路径。
＊＊＊＊备份环境注意点：
1、确保没有其他进程访问版本库，关闭apache、svnserve服务
2、成为版本库的管理员，如果以其他身份还原版本库，可能会改变版本库文件的访问权限，导致在恢复后依旧无法访问
3、svnadmin recover/path/to/repos
4、重新启动服务进程
SVN数据库整理方法:(不经过dump,load操作,实现SVN数据库整理操作)
先设计好调整后的目录, 然后打开版本库,选中要调整或转移的文件(文件夹)-->右键拖住,不要松手-->然后将要转移的文件(文件夹)拖至目标文件夹-->松手-->选择moveitems to here-->完成
每经过这样的调整,大家都会担心历史记录是否还会存在, TortoiseSVN在默认情况下,是不会显示出来的,需要将一个选项去除.
如此可实现基于库的调整操作,但事事不是尽如人意的,这样的一次操作下来,revision会增长好多.
我的想法是:
停止当前SVN服务,将当前的SVN库直接进行整理,就像整理存储在电脑中的文件夹一样,然后开启SVN服务,即时显示调整后的效果,哈哈..是不是有点异想天开,其实我也觉得这是不太可能的,除非使用工具访问,否则SVN库不是显示可见的,希望以后啥配置管理工具可以让管理员有这样的权限.