我的问题与SVN合并机制的一些基本原理有关。我没有在这里报告合并问题。此外，我已经阅读了 SVN 书的合并章节（不是新手）。
我在主干上有 10 个修订版，我想将修订版 5、6、7、8、9 和 10 合并到特定标签。
通过运行 6 次合并操作，我可以在 tortoise SVN 中成功合并。每次我只指定一个版本（即 5、6、7、8、9、10）。
如果我对 SVN 修订版的理解是正确的，那么修订版 10（HEAD 修订版）具有以前修订版的所有修复，即 5、6、7 和 9。因此，我可以通过只运行一次合并操作来节省时间，即通过指定修订版 10。
对我的问题的明显反应是我应该指定一个“修订范围”。
我的问题是为什么即使在修订版 10 包含以前修订版的所有更改时还要指定一个范围（http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.basic.in-action )? 我不能只通过指定单个修订版（第 10 号）进行合并并期望 SVN 进行正确的合并吗？
实际上，该svn merge命令将差异（或变更集）作为参数。因此，当您使用如下命令进行合并时：
svn merge -c10 URL
它实际上与以下内容相同：
svn merge -r9:10 URL
并将第 10 次提交带来的更改合并到存储库。
此外，该svn:mergeinfo属性将指示与修订版本 10 对应的变更集已被合并，因此后续合并将更智能，并且不会尝试第二次合并该变更集。
因此，为了具体回答您的问题， svn merge当您想要合并与该特定范围相对应的更改时，您可以指定命令的修订范围。
文档中有关于更改和变更集的通知：
在 Subversion 中，全局修订号 N 命名存储库中的一棵树：这是存储库在第 N 次提交之后的方式。它也是一个隐式变更集的名称：如果您将树 N 与树 N-1 进行比较，您可以得出提交的确切补丁。出于这个原因，很容易将修订 N 视为不仅仅是一棵树，而且也是一个变更集。如果您使用问题跟踪器来管理错误，则可以使用修订号来引用修复错误的特定补丁——例如，“此问题已由 r9238 修复”。然后有人可以运行 svn log -r 9238 来了解修复错误的确切变更集，然后运行 svn diff -c 9238 来查看补丁本身。而且（你很快就会看到）Subversion 的 svn merge 命令能够使用修订号。