这些天一直被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服务。
完成了以上步骤后，客户端和服务器端都可以正常使用了。
这时，当完成一次合并后，再合并时就会发现已合并的版本变成了灰色。