有时当我从trunk合并一个项目时，即使我的版本和主干之间没有区别，一些文件也会被修改（即，需要通过合并签入）。比较显示它们完全相同，即使白色空间也没有不同。
答案 0 :(得分：3)
您可能会看到的一件事是在合并期间文件更新的报告，即使它不是。这可能是由于更新了该文件或目录上的svn:mergeinfo属性。
通常，只有项目的根目录应该有一个svn:mergeinfo属性，因为您几乎总是从项目的根目录合并。但是，一些开发人员习惯于合并单个文件和目录，因为他们知道这些已被更改。当开发人员这样做时，Subversion开始使用他们自己的svn:mergeinfo属性跟踪这些文件和目录的合并。
现在，当您进行合并时，即使文件本身未更改，也必须更新所有这些svn:mergeinfo属性。毕竟，Subversion STILL必须跟踪您是否进行了特定的合并，即使它没有影响该文件，以便能够跟踪已经合并的内容。
如果问题svn:mergeinfo，请不要还原文件。否则，Subversion将一遍又一遍地重做无用的合并。您可以尝试从该特定文件的主干和分支中删除svn:mergeinfo，但请注意不要忘记合并的内容。
Subversion中的合并不像它应该的 cleancut 。 Subversion识别两种不同类型的合并：
reintegration 概念是必需的，因为您的分支包含您已从主干合并到分支 AND 的内容，该分支是不是在树干本身。您不希望将已合并到分支中的内容再次放置在主干中，因此 reintegration 功能仅将分支上的工作复制回主干（它实际上是双向合并）。完成此操作后，您必须非常小心再次合并回该分支。
为什么？：该分支上的所有更改都已合并到主干中，从而创建了新的主干修订版。如果您执行新的Subversion主干分支合并，Subversion将看到合并创建的新修订，并尝试将新修订包含的所有更改重新合并到分支中。
要处理此问题，请使用合并的--record-only选项将新修订从trunk更新回到分支。现在，当您从主干合并回分支时，将不会考虑将 new 修订版用于合并：
$ svn co $REPO/trunk
$ cd trunk
$ svn merge --reintegrate $REPO/branch/1.2 #Two-way Reintegrating branch 1.2 to trunk
$ svn commit -m"Reintegrate 1.2"
commit revision 12345
合并创建了修订版12345.这必须仅记录回到分支，以便我们能够重用分支：
$ svn co $REPO/branch/1.2
$ cd 1.2
$ svn merge -c 12345 --record-only $REPO/trunk
$ svn commit -m"Mark Reintegrate Merge as completed"
- 怎么会这样？它与mergeinfo有关吗？
是的。您可以从中继和分支中删除该文件中的svn:mergeinfo信息。但是，你需要小心。或者，你可以忽略它，因为你知道它没关系。
- 考虑到没有变化，没有将这些文件签入我的分支有什么副作用......
Subversion将在下次合并每次合并时再次尝试合并时间越来越长，因为每次必须合并更多版本。
- 当我尝试合并回主干时会不会有麻烦？
当您从分支合并到主干时，必须使用--reintegrate参数来防止分支将更改重新更改回主干。重新整合合并仅使用双向合并。这基本上使trunk与分支匹配。
完成此操作后，您必须注意从主干到分支的新合并。
答案 1 :(得分：1)
大卫在大多数（并非所有）方面都是正确的，与“Merge-Hell”有关。但我想对一些具体细节
进一步阐述svn diff 修改后的工作副本将在WC中显示所有更改，svn diff在两个节点之间显示（mergeset和合并源） ）也会显示所有这些细节 - 试试