views:

990

answers:

3

I just did an svn merge to merge changes from the trunk to a branch:

$ svn merge -r328:HEAD file:///home/user/svn/repos/proj/trunk .
--- Merging r388 through r500 into '.':
A    foo
A    bar
   C baz1
   C baz2
U    duh
[...]

But there were too many conflicts, so I'd like to undo that.

One way to do that is to commit and then merge back. But I can't commit because of the conflicts. What's the best way to undo in that case?

+2  A: 

As long as you haven't commited, you can always do a revert to undo all your changes.

tangens
Hmm, just `svn revert .` didn't do anything.
OK, then you should resolve everything first, then do the revert.
tangens
...and like @rq said, don't forget the -R flag to do the revert recursively.
tangens
+8  A: 

Revert recursively from the top of your working copy:

svn revert -R .

You will need to manually delete the files that were added. As in after reverting, the files added will remain on disk but they will be in a non-tracked state ("? foo")

rq
A: 

Just do svn resolve on all conflicts anyway and commit:

$ svn resolved baz1
$ svn resolved baz2
$ svn ci -m "oops. bad merge. will revert."
Transmitting file data ......
Committed revision 501.

Then, officially undo it by merging back to where it was:

$ svn merge -r501:500
--- Reverse-merging r319 into '.':
[...]

That's it, the merge has been undone in the directory. Now commit that too:

$ svn ci -m "bad merge has been undone"
Transmitting file data ......
Committed revision 502.

The advantage over the svn revert -R . method is that the files that were added are all properly removed.

Found this out myself, so I'm answering my onw question. :)
This is totally *not* the way you should have done it!
rq
You don't really want to be puking conflict markers into your repository's *permanent* history, do you!? Yuck.
bendin
bendin: To be fair, it is *history* and not working copy.
Lakshman Prasad