SVN服务更换小记（由subversion更换为VisualSV

本次迁移遇到的一些问题和网上找到的解决方案，我都列在文末了，作为以后的回顾。

近期由于原svn服务（apache+Subversion）在配置权限的时候会出现写入配置后保存，整个svn项目都无法访问的情况，并且一直定位不到原因，非常严重影响工作效率。因此决定用一个一劳永逸的办法--更换服务，来解决这个问题。

无意中发现其实有VisualSVN Server可以用图形化的方式来管理版本库，再加上它不像apache+svn的方式那样，需要繁琐的配置，最重要的是，这个服务它完成是免费的，瞬间被打动。经过试用，也确定这个东西好用，便决定就用它，来取代现在的服务器上1.4版本的svn服务。

因为本身服务器是32位 windows server 2003，纵visualsvn server有再高的版本（现在最新版本应该是3.9.1，https://www.visualsvn.com/server/download/，这是最新版本的下载链接，有32位和64位），能支持03系统的，我选择了2.6.5版本（我放在百度网盘，需要的请自取：https://pan.baidu.com/s/13giBFS7XzP6gB7Gn0nS2cQ ）。下载安装一气呵成，超简单。

这里并不是要来讲配置过程的，因为它在安装的过程就没有难点。我要记录的，是使用过程中遇到的一些问题。

第1个问题（已解决）：

使用dump迁移的过程中，导入的时候出现一个情况，提示svnadmin:Expected fs format "2";found format "6"。

原因：网上找了找原因，说是服务版本不一致导致的。我突然想到，我是从svn1.4中导出，需要导入到是其他类型的svn服务，但是用的仍是旧svn的命令路径。

解决：于是把导入路径由原来的svn更换为visualsvn再导入，导入成功。（测试了一下，从原svn服务dump出项目的时候，用visualSVN的路径也可以）

第2个问题（已解决）：

导入的项目，从小乌龟上查看项目列表时，可以看到 author和date 的记录是有保留完整的，但是show log的时候，提示却是日志路径path not found

9月3

周五的时候，在网上找了一个下午，居然都没有找到解决这个问题的答案，是我太菜

（T T）。都准备要放弃了。

今天周一，本来准备大干一场，找不到答案誓不罢休的。却在切换旧有svn服务项目和现visualsvn服务项目的时候，无意中发现，日志居然出现了。反复确认了一下，日志确实是正常显示了。

一开始我以为是项目迁移后，visualSVN服务需要一段时间来加载日志文件。为了确认，又迁移了一个旧项目到visualSVN，结果在小乌龟上show log，项目的log又全都显示出来。

原因：再看看show log 时的项目路径，我才发现，提示path not found，我用小乌龟repo-browser时用的访问路径，是http://localhost:port/svn，也就是svn的根目录。这样从根目录展开项目的时候，会在根目录后方多加一个“/”，所以在对项目进行show log的时候，log的路径就变成了http://localhost:port/svn//project/ --log message，当然就会有path not found的情况。

图1

解决：把这个多余的“/”去掉，访问log就毫无压力了，因为毕竟dump导出的，可是全方位的项目信息。

所以建议不想多操作一个‘去掉多余符号’的动作的同仁们，repo-browser时，在svn根目录后跟上项目路径。

所以有时候，在找到问题出在哪儿之前，真的是大问题大毛病，找对问题的方向很重要。

9月5

dump过程和load过程充满艰辛，由于一个版本库中放了很多项目，而且版本的历史也是条长河，dump的过程频繁出错，全量导出和增量导出都尝试过，都失败，网上的解决方法也试过，也没有太大的解决希望。因此决定用笨方法，直接在本地用小乌龟，一个项目一个项目地迁移，这样势必就造成了日志的丢失，目前只是采用了笔记本，把日志都导出保存，然后上传到新库中，查阅使用。

第3个问题（已解决）：

即便采用笨方法，也不是一帆风顺的。在项目迁移之后，我先尝试使用简单变更关联的方式实现本地项目与新库的连接，即在eclipse的资源库里重新定位，但出现了以下提示：客户端和服务端uuid不一致。

uuid不一致

原因：出现这个问题的原因就是SVN服务器上仓库的uuid和我们本地仓库中的uuid不一致。uuid是SVN服务器在创建仓库时自动生成的一个随机数，通过这个随机数用来判断服务器和客户端的仓库是否一致，如果不一致，就会引起冲突。

解决方法：在客户端修改该仓库中每一个本地项目的uuid。（项目多的时候，这也是一项大工程。当然还有一个办法，就是重新checkout项目，不过这个只适用于本地项目与新址项目完全一致的情况。）

解决步骤：

1，获取svn服务的uuid。要让本地与版本库上的uuid保持一致，首先要知道版本库的uuid。有3种方法可以知道uuid。第1可以直接从eclipse重定位失败后的报错控制台中复制。正常情况下，是前面那一段。

从控制台复制服务uuid

第2如果项目太大重定位担心时间太长，可以直接在服务器对应的版本库中找。目录是Repositories\版本库\db，可以看到里面有一个uuid文件，用记事本打开就可以，里面那串字符就是了。第3也可以在visualsvn server控制台中找到对应的repository，右键查看【Propertity】，然后在Details标签页中可以看到这个仓库的uuid了，这里的uuid也可以直接复制。我的是visualsvn server 2.6.5，并没有这个details，不知道是不是支持高版本的。

2，修改本地每个项目.svn\wc.db数据库，表REPOSITORY中的uuid字段。这里.db文件编辑我用的是SqliteDev，软件我放到网盘了，有需要的自取。（https://pan.baidu.com/s/1epQOj315PJ2v6jV0yZhn0g）

SqliteDev操作简要说明：

    --注册数据库->数据库选择wc.db，别名用于显示，随意；

    --展开表->在REPOSITORY右键‘查询数据’打开编辑窗口

查询表数据

    --在编辑窗口，输入更新语句更新uuid（update REPOSITORY set uuid='这里输入刚才复制下来的uuid'，然后执行查询操作，即为更新成功，无需附加操作）

更新uuid

    --更新完成，需要注销数据库，否则可能会在重定位时提示被占用

注销数据库

更新uuid后，重定位操作顺利。查看本地项目的svn版本控制地址，更新成功，即说明重定位成功。

注意：每个版本库的uuid是不一样的（\svn\版本库\db\uuid），如果是操作不同的版本库，需要从不同的版本库中拿uuid去操作。

当然服务变更后，除了重定位，还可以采用断开连接再重新连接的方式来与新域名的项目进行关联。我之前有介绍过，有需要可以到这个地址了解。

https://www.jianshu.com/writer#/notebooks/27288935/notes/5337141

第4个问题（已解决）：

问题：重新定位时，提示“svn: Invalid relocation destination: '（这里紧跟新资源库地址' (does not point to target)”

原因：在checkout项目时，没有使用svn上的名称作为本地项目名称，导致新库无法识别要连接的本地项目。

解决：这个有2个解决方式。1，将本地目录名称改为与线上一致（这个方法大家可以试试，因为目前没有其他项目重定位的需求，所以没有试过是否有用）。2，使用项目断开重连的方式，使本地项目与新库建立连接。因为这个我之前有写过，请移步以下地址查看第二种方式：https://www.jianshu.com/p/a9c985bee443

迁移过程问题及解决相关链接

浅谈SVN服务器迁移的一些注意事项：https://blog.csdn.net/liang383781357/article/details/78846124

svnadmin load 遇到E125005 的错误：https://blog.csdn.net/powerccna/article/details/9949739

SVN版本库的备份、还原、移植（初级篇、中级篇和高级篇）：https://blog.csdn.net/aa4790139/article/details/26229793

SVN版本库的迁移 dump的详细使用：https://blog.csdn.net/hzfw2008/article/details/78082685

VisualSVN跨版本库迁移目录（保留日志）：https://blog.csdn.net/helenfish/article/details/9984555

后记：

由于热备的需要，又在本地安装了一个visualsvn服务。安装之后默认使用的是https访问协议，端口443。这个可以改为http。打开控制台，右键根节点，打开属性窗口：

打开属性窗口

切换到网络子标签：如下：去掉使用https协议的勾选，确定即可。

2019年1月25

迁移过程所花费的时间，取决于项目版本号的多少，及项目变更历史。

迁移包括从原库中迁出，和迁入到新库。从原库中迁出时，取的是所有版本号，与文件变更数量无关，所以迁出往往花费的时间会比较少，1g左右的项目文件，可能几分钟就完成了迁出。而迁入到新库时，导入的是所有变更，也就是所有版本号以及该版本下文件的增删改查，逐一导入。还是1g的文件，大概4000个版本号，花费时间在45分钟~1个小时以内。不过这只是本人在项目导入时的一个计量，可以参考，但不作为绝对的平均数。