问题
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
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]]
(Files 1, 2, and 6 reside elsewhere)
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.
回答1:
This is expected behavior for --dry-run, which does not modify the filesystem.
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.
In detail:
- r21358 modifies File 4.
- In a normal merge, File 4 now has local changes and r21364 merges those changes together because the diff matches the current state of the file.
- In a dry-run, File 4 was not changed by r21358. The file does not match what the next revision, r21364, expects it to be, so you get a conflict instead.
- The same things happens with r21373 - either r21370 or r21371 modified the same part of the file that it applies to.
- r21371 does not suffer from this because it affects a different part of File 5 than r21370.
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.
来源：https://stackoverflow.com/questions/16527916/svn-merge-dry-run-show-svn-diff