问题描述
我正在使用一个代码库,该代码库(历史上)是手动合并的,而不是通过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的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!