4

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.

4

1 回答 1

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.

于 2013-12-20T20:15:38.420 回答