本文接着上篇文章继续报道Subsverion版本升级、兼容性以及Subversion合并跟踪问题，欢迎大家一起来讨论研究。
Subversion1.5支持的合并跟踪是“基础的”：最重要的部分已经实现，但是在我们最初的规格中还有一部分需要去实现（特别是对于reflectivemerges的正确支持，更好的change-availabilityreporting和更好的trackingofrenamedfiles），虽然在1.5还要加入一些主要的特性，但我们不希望为等待某个特性延迟我们的发布。更多的合并跟踪改进希望在Subversion1.6或以后的版本出现。
概述Subversion的合并跟踪设计为：
◆减少分支维护的记录负担
◆防止常见的“重复合并”问题
◆允许对于变更的cherry-picking
每个变更集都可以通过修订版本号识别，通过新的svn:mergeinfo属性在合并的目标存放在合并变更集的信息（通俗来说就是“合并信息（mergeinfo）”），Subversion会自动保持合并信息的为最新，但是也有办法手工记录/消除合并信息，这是因为总会有些时候人们知道一些Subversion不知道的事情。用户界面从主干合并分支不再需要指明修订版本范围，每当你希望与trunk同步，你可以这样做：
$cdBRANCH_WORKING_COPY
$svnmergeURL_TO_TRUNKSubversion能够计算出从URL_TO_TRUNK有哪些变更没有合并，并只处理这些变更，当将分支合并回主干，我们只需要：
$cdTRUNK_WORKING_COPY
$svnmerge--reintegrateURL_TO_BRANCH下面是所有合并跟踪相关接口变更的正式描述。
svnmerge命令使用两个新的选项：--record-only和--reintegrate。
–record-only选项至于-r结合工作，并且和你所想的一样：它只是用来将修订版本标记为已合并（或未合并的，使用“-”作为否定语法），而实际上除了合并信息（mergeinfo），什么也没有做。例如，当因为效率某个人手工修改了这个文件而合并了这个其他地方修改的变更时，这非常有效，与其让让变更在下次合并时加入进来，从而引起文本冲突，我们不如记录这个变更已经合并。（细节见Subversion书的merge-trackingrequirements,andBlockingChanges。）–reintegrate选项在将分支合并回主干时使用；它会检查一些防护措施条件并快速有效的进行合并，更多内容见Subversionbook的Keepingabranchinsync。新的svnmergeinfo命令可以显示一个目录已经接收的变更集，以及哪些变更集还适合接收，Subversion手册的MergeinfoandPreviews有更多信息。svnlog和svnblame命令有了新的-g(--use-merge-history)选项，使之将mergeinfo纳入考虑，如果没有提供这个选项，它们就会参考合并信息。
使用-g选项的原因是有时候忽略合并历史会更好，在blame输出中，有时候你希望看到合并变更的人物B，而有些时候你希望看到最初作出这些修改人物A；使用-g可以得到后者的信息。在日志输出中，你有时候希望看到某一行提交的修订版本，而有时你希望看到最初的修改做合并修订版本转移走了；再次，-g显示后者的信息（使用”Mergedvia:“标识，后面是合并发生的修订版本号码），见Subversion手册的Merge-SensitiveLogsandAnnotations。Subversion合并跟踪和兼容性前面已经说了，在随server升级版本库以前不支持合并跟踪。
如果你正在使用svnmerge包裹程序来进行合并，而现在希望使用Subversion1.5本身的合并跟踪功能功能，你一定要使用svnmerge-migrate-history.py脚本来转化svnmerge的自定义属性为Subversion使用的svn:mergeinfo属性。
已知问题1.5.0的合并跟踪还有许多已知的问题，我们首先解决了最重要的，下面是：
◆issue#3128:merge--reintegrate应该更好的处理重命名
◆issue#2897:对反向合并的更好支持
◆issue#3126:更好已知变更报告（svnmergeinfo显示了太少或太多的合适修订版本）
◆issue#2837:当执行循环合并时合并跟踪能起效果
◆issue#3056:防止以智能方式重复合并
◆issue#2898:当删除/添加子时无需处理合并信息
◆issue#3067:在合并范围内不存在的树不应该破坏合并
◆issue#3157:从路径的自然历史合并变更会创建引用自己的合并信息
◆issue#3174:合并算法需要对重命名的子树特别关注
（可以看listofallmerge-relatedopenissues，尽管很多不是关于Subversion合并跟踪）
Issue#3157可能是会很容易遇到的，所以下面是如何解决这个问题的详细描述：合并跟踪信息现在可以保存在路径的“本身历史”中，当从trunk的特定修订版本x创建了一个分支，然后将分支的所有变更合并回trunk时，如果没有明确的限制合并范围并且没有使用--reintegrate选项时，后果是，trunk的合并跟踪信息将会列出x之前的信息。这对以后的合并操作没有坏处，但是对于trunk上的svnlog-g会使用以前修订版本的合并跟踪信息（而不只是HEAD）。
注意，这一定不会是一个发布分支（也叫做“维护分支”）的问题，因为一个人通常不会将其合并回主干，相反，推荐的时间是对于进入trunk的新变更使用特性分支，可以在分支的生命周期结尾一次合并到主干。 一个办法是在提交合并修订之前修正合并跟踪信息，通过恢复“本身历史”信息：svnmerge--record-only-rX:1。另一个方案是完全防止这种情形，通过在第一次就明确的指定合并范围，例如-rX:HEAD，更多信息可以看这个邮件。 当Subversion合并一个特性分支，最佳方案是使用--reintegrate选项。
【编辑推荐】
