svn merge --dry-run显示svn diff [英] svn merge --dry-run Show svn diff

问题描述

我正在使用一个代码库，该代码库(历史上)是手动合并的，而不是通过svn merge合并的.我正在尝试通过向所有人证明合并的有用性来改变这种情况-但是当我进行试运行时，会得到以下提示:

I'm working with a codebase that has (historically) been merged by hand rather than via svn merge. I'm trying to change that by proving to everyone how useful merge is - but when I do a dry run, I get this:

$ 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吐出两个冲突更改之间的差异，我会喜欢的.

I have two files (listed as 4 and 5, respectively), that survive one merge only to pop a conflict with the last one. I'm trying to figure out what that conflict is now, and see if I can resolve it. I'd like it if I can force svn to spit out the diff of the two conflicted changes.

我签出了一个最窄目录的新工作副本，当我在没有空运行的情况下运行合并时，我得到了:

I checked out a new working copy of just the narrowest directory, and when I ran the merge without dry run, I got:

--- 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位于其他位置)

(Files 1, 2, and 6 reside elsewhere)

所以，现在我特别困惑-空运行报告了冲突，但是当合并实际运行时，成功了吗?这是预期的行为吗?我承认我不是SVN向导，但我很困惑.

So, now I'm especially confused - dry run reports a conflict, but when the merge is actually run, it's successful? Is this intended behaviour? I'll admit I'm no SVN wizard, but I'm left quite bewildered.

推荐答案

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

This is expected behavior for --dry-run, which does not modify the filesystem.

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

Because you specified individual revisions, those revisions are being applied separately, one after another. The G in the merge output means that a merge occured - svn made a change to a file that already had a local change.

详细信息:

• r21358修改文件4.
• 在常规合并中，文件4现在具有本地更改，而r21364将这些更改合并在一起，因为diff与文件的当前状态匹配.
• 在空运行中，r21358并未更改文件4.该文件与下一个修订版r21364所期望的不匹配，因此您会遇到冲突.
• r21373发生相同的事情-r21370或r21371修改了文件所适用的相同部分.
• r21371不受此影响，因为它与r21370相比影响文件5的不同部分.

一旦您克服了所有这些麻烦，就可以一次性合并所有这些，而不必指定单独的修订，并且自动运行与常规合并之间的区别也将消失.

Once you're past all these hiccups, you'll be able to merge all of these in one go, without having to specify individual revisions, and this difference between dry-run and a regular merge will just go away.

这篇关于svn merge --dry-run显示svn diff的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！