本文介绍了svn merge --dry-run显示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的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-22 15:47