Question

我正在使用（历史上）手工合并而不是通过svn merge合并的代码库。我试图通过向每个人证明合并是多么有用来改变它 - 但是当我做一个干运行时，我得到了这个：

$ svn merge [[Repo URL]] . -c 21355,21358,21364,21370,21371,21373 --dry-run
--- Merging r21355 into '.':
U    [[File 1]]
--- Merging r21355 into '[[dir]]':
U    [[dir]]/[[File 2]]
U    [[dir]]/[[File 3]]
--- Merging r21358 into '[[dir]]':
U    [[dir]]/[[File 4]]
--- Merging r21364 into '[[dir]]':
U    [[dir]]/[[File 2]]
C    [[dir]]/[[File 4]]    
--- Merging r21370 into '[[dir]]':
U    [[dir]]/[[File 5]]
--- Merging r21371 into '[[dir]]':
U    [[dir]]/[[File 5]]
--- Merging r21373 into '[[dir]]':
C    [[dir]]/[[File 5]]
U    [[dir]]/[[File 6]]
Summary of conflicts:
  Text conflicts: 2

我有两个文件（分别列为4和5），只有一个合并才能与最后一个文件冲突。我正在试图找出现在的冲突，看看我是否可以解决它。如果我可以强制svn吐出两个相互冲突的变化的差异，我会喜欢它。

我查看了最窄目录的新工作副本，当我在没有干运行的情况下运行合并时，我得到了：

--- Merging r21355 into '.':
U    [[File 3]]
--- Merging r21358 into '.':
U    [[File 4]]
--- Merging r21364 into '.':
G    [[File 4]]
--- Merging r21370 into '.':
U    [[File 5]]
--- Merging r21371 into '.':
G    [[File 5]]
--- Merging r21373 into '.':
G    [[File 5]]

（文件1,2和6位于其他地方）

所以，现在我特别困惑 - 干运报告冲突，但是当合并实际运行时，它是否成功？这是预期的行为吗？我承认我不是SVN巫师，但我很困惑。

Answer 1

这是--dry-run的预期行为，它不会修改文件系统。

由于您指定了单独的修订版，因此这些修订版将一个接一个地单独应用。合并输出中的G表示发生了合并 - svn对已经发生本地更改的文件进行了更改。

详细说明：

r21358修改文件4。
在正常合并中，文件4现在具有本地更改，并且r21364将这些更改合并在一起，因为diff与文件的当前状态匹配。
在干运行中，文件4未被r21358更改。该文件与下一个版本r21364的预期不符，因此您会遇到冲突。
r21373也是如此 - r21370或r21371修改了它适用的文件的相同部分。
r21371不会受此影响，因为它影响文件5的不同部分而不是r21370。

一旦你经历了所有这些打嗝，你就可以一次性合并所有这些，而不必指定单独的修订，干跑和常规合并之间的差异就会消失。 / p>

svn merge --dry-run显示svn diff

1 个答案: