SVN服务器迁移实战

　　作为代码管理主流工具，SVN的优劣自有程序猿界的各位大拿评说，在此不再赘述。

　　由于公司使用移动网络的缘故，时不时的出现svn代码管理平台无法上传和更新文件的问题，这对于程序猿来说就好像战场上的战士武器被缴一样致命，如果不是程序猿天生的隐忍和同理心，恐怕会引起异常暴动也未可知，所以移动网络处理不给力，迁移svn平台至内网成为唯一方案，已刻不容缓。

　　任何一种迁移方案都必须满足几个条件才算迁移成功：1、各历史版本信息要迁移 2、源文件迁移 3、用户要迁移 4、权限要迁移

　　一开始我想的挺简单，建一个svn服务，把源包的文件拷贝过来就行了，在实施的过程中发现不满足以上的条件1，但是用户和权限的迁移倒可以采用这个方案。后来才用svn自带的dump工具将源备份，包括历史版本一并打包，在打包的过程中才知道2年来我们更新了将近30000个版本，产生了将近18G的源文件，打包命令：svnadmin dump E:RepositoriesWJ-SVN > E:RepositoriesWJ-SVNWJ-SVN.dump，如果在执行的过程中发现提示此命令无效非内部命令，说明该命令未列入环境变量，需要进入到SVN的安装路径下进行操作就可以了。

　　打完包后近18G的文件如何迁移倒成了问题，直接复制拷贝文件太大基本不可能，拷到U盘再拷出来时间太长，不是最优方案，于是将源文件压缩到10G左右先临时上传到我们的一台云服务器上，然后再下载下来，当然此过程用时大概也有7个小时。

　　接下来就是解压导入了，命令Svnadmin load E:RepositoriesWJ-SVN < E:RepositoriesWJ-SVNWJ-SVN.dump。

　　特别的，目标文件夹的创建最好也是用svn命令：svnadmin create E:RepositoriesWJ-SVN，这样确保创建遗漏。