views:

44

answers:

1

If you've done a merge you may find, before committing the changes, that actually you don't want to accept any of the changes merged into one of the affected files. So you do e.g.:

$ svn revert foo.c

However this also seems to revert the mergeinfo related to this file. So when you do a subsequent merge it will merge in exactly the same changes again.

Rather than revert one could do:

$ svn cat foo.c > foo.c

But this doesn't seem like the right way to do things? Is there something that more clearly indicates what I'm trying to achieve, i.e. to say "consider the merge done for this file but don't change its contents"?

+1  A: 

To block a revision from getting merged, run the merge command with the --record-only param.

Stefan
In my situation I'm usually merging a large tree of files. I want to do a _real_ merge and to accept most of the merged changes. I'm just talking about the situation where on reviewing the merge I decide that, out of many files with changes merged into them, there are one or two files where I don't want to accept the changes, but still want the merge to be considered done for these files as well as all the others once I've completed the commit. I could revert the changes for these one or two files and then do merge with --record-only for these specific files but this seems long winded?
George Hawkins
Then don't use the revert command but undo the changes in a visual diff tool.
Stefan