SVN服务更换小记(由subversion更换为VisualSVN)

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

近期由于原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个小时以内。不过这只是本人在项目导入时的一个计量,可以参考,但不作为绝对的平均数。