我的问题涉及SVN合并机制的一些基本原理。我在这里没有报告合并问题。此外，我已经阅读了SVN书的合并章节（不是新手）。
我在主干上有10个版本，我想将修订版5,6,7,8,9和10合并到一个特定的标签。
我可以通过运行合并操作6次成功合并到陆龟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做正确的合并吗？
答案 0 :(得分：0)
实际上，svn merge命令将diff（或changeset）作为参数。所以当你使用这样的命令合并时：
svn merge -c10 URL
它实际上与：
相同svn merge -r9:10 URL
并且正在将第10次提交带来的更改合并到存储库。
此外，svn:mergeinfo属性将指示对应于修订版10的变更集已经合并，以便后续合并将更加智能，并且不会尝试第二次合并该变更集。 / p>
因此，要具体回答您的问题，当您要合并与该特定范围相对应的更改时，请指定svn merge命令的修订范围。
the documentation中有关于更改和更改集的通知：
在Subversion中，全局修订号N命名为树中的一棵树 存储库：它是存储库在第N次提交后的方式。 它也是隐式变更集的名称：如果比较树N. 使用树N-1，您可以派生出已提交的确切补丁。对于 这个原因，很容易将修订版N认为不仅仅是一棵树，而是 变更集也是如此。如果您使用问题跟踪器来管理错误，那么您 可以使用修订号来引用修复的特定修补程序 错误 - 例如，“这个问题由r9238修复。”有人可以 运行svn log -r 9238来读取修复的确切变更集 bug，并运行svn diff -c 9238来查看补丁本身。而且（就像你一样 稍后见）Subversion的svn merge命令能够使用修订版 数字。您可以将特定变更集从一个分支合并到另一个分支 通过在合并参数中命名它们：将-c 9238传递给svn merge 将changeset r9238合并到您的工作副本中。