我正在尝试使用--dry-run选项测试冲突，以下是我的命令：
svn merge -c4461,4462 --dry-run https://<Confidential-URL>/svn/repos/transitionportal/branches/BR_3591_MULTILINGUAL
此命令的输出显示存在冲突。以下是输出：
--- Merging r4461 into '.':
U test\testfile.txt
--- Merging r4462 into '.':
C test\testfile.txt
Summary of conflicts:
Text conflicts: 1
然而，当我直接进行合并，即没有--dry-run选项或使用Tortoise SVN GUI进行合并时，它会直接合并而不会产生任何冲突。
--- Merging r4461 into '.':
U test\testfile.txt
--- Recording mergeinfo for merge of r4461 into '.':
U .
--- Merging r4462 into '.':
G test\testfile.txt
--- Recording mergeinfo for merge of r4462 into '.':
G .
干跑的任何原因都是冲突？ 有人请帮助我。
提前致谢...
答案 0 :(得分：1)
这很有趣。我无法在不查看历史记录和相关文件的情况下说出来，但我愿意假设修订版4461在testfile.txt中进行了更改，以防止它在修订版4462中发生冲突。
我们假设您已经修订了4000版，您在修改版4450上对您的分支进行了一次更改，现在您将更改4461和4462从您的主干合并到此分支。
可能是4461的合并以某种方式修复了Subversion在版本4450和修订版4462之间检测到的冲突。毕竟，干运行实际上并没有修改所触及的文件。如果发生这种情况，我无法想象一下这种情况。你以前是否有可能将当前的工作目录合并到分支机构，而且修订版4461会包括那个？）
当您使用-c参数时，会同时合并一个更改。这两个是等效的：
$ svn merge -r45:46 ...
然而，这些并不完全相同：
$ svn merge -c45,46 ...
$ svn merge -r44:46 ...
第一个将合并两次（如您所见。它合并版本45，然后合并版本46）。第二个创建更改集并合并该更改集，因此只进行一次合并。据我所知，最终结果是一样的，但操作不同。
看看你是否这样做会很有趣：
$ svn merge -c4460:4462 ....
看看你是否有同样的合并冲突。
对于广泛的答案感到抱歉。在不查看合并历史，共同祖先和之前的变化的情况下，总是很难说Subversion正在思考什么。当一个分支中的工作（比如更改一条线）也发生在第二个分支中时，就会发生合并冲突。我无法直接了解初始合并将如何解决这个问题，但显然确实如此。