linux 升级 repository,CentOS上升级Subversion

这些天一直被SVN的分支间的合并(Merge)折磨的够呛，大家也都反映：在连个分支之间合并太麻烦了，有时候根本不知道上次合并了哪个版本。当时想了一些方法，争取从流程上防止出现错误：

1. 每个人都只合并自己的修改

有时候一个fix会涉及多个人的修改。

2. 每一个fix就合并一次，以免修改太多，记不清

大部分时候一个fix都要反反复复修改，并且修复的同时，可能还会新的需求过来。

3. 合并后提交时，在注释中写明合并到了哪个版本。

虽然可以写的清楚，但是在log中也不好查找，而有时候合并是要跳过某些版本的。

大家都在“抱怨”这个合并过程，并且前几天还出现过一次严重的问题。当时，由于着急发布，而合并时又出现了，开发人员就用主分支中的最新内容覆盖了发布分支中的代码，一些还没有测试的代码就被发布了。还好那天没有出现大的问题，随后就有稳定版本上线。一个很现实的问题摆在了眼前：如何才能很好地跟踪合并历史？？

有高手推荐了Git，我本人并不对反对使用Git，但是现在改用Git，必然会带来更多的学习开销。不过好像也没有别的方法，就开始尝试git。在Git的介绍中，提到了一个显著的特性就是合并跟踪，而最意外的收获就是：SVN从1.5(2008年呀！再次鄙视一下自己的孤陋寡闻)开始就支持合并跟踪了。那就继续使用SVN了。      先交代一下项目中使用SVN的场景：CentOS，Apache2 + Subversion

到服务器上看下当前SVN服务器的版本(svn --version)是1.4，首先想到的就是升级：

# yum update subversion

还是真有福气呀，现在Cent OS中的仓库中已经有了1.6.11。

然后在本地工作目录使用TortoiseSVN更新，得到错误信息：could not open the requested svn filesystem。在服务器上查看httpd的error.log，发现了：(20014)Internal error: Expected FS format '2'; found format '4'。

原来服务器端程序升级完以后，仓库也需要升级：

# svnadmin upgrade myrespository

仓库升级完毕后，重新启动httpd，再使用用TortoiseSVN更新时，又得到了另外的错误：Can't open file '/var/www/svn/myrepository/db/txn-current-lock': Permission denied。看起来是权限有问题，不过myrepository的权限都属于apache.apache，好像是没有问题。于是进入myrepository，查看个子目录或者文件的权限，发现其中一个新文件format属于root.root。和其他目录下的format进行对比，果真是这个文件有问题，使用：

# chown apache.apache format

进行修改。然后再重启httpd服务。

完成了以上步骤后，客户端和服务器端都可以正常使用了。

这时，当完成一次合并后，再合并时就会发现已合并的版本变成了灰色。