svn revert after merge

Question

I've done an svn merge between two branches -- not checked in -- and now I want to "un-merge" some of the files in my working copy. Something like the following:

svn co svn://myserver/repo/branches/foo@1000 foo
cd foo
svn merge svn://myserver/repo/branches/foo@1000 \
          svn://myserver/repo/branches/bar@1000

(Note: I want to use svn merge , and not just copy the files from a working copy of bar , because (1) there are some legit merges, ie unrelated changes made on foo and bar to the same files, and (2) some files have been deleted in bar and I when I check in I want to delete them from foo as well.)

I want to check in most of the merged files, but some of them, I want to throw out the changes from bar branch and keep the existing file from foo branch. So I try:

svn revert baz/qux.quux

This does nothing. qux.quux still has the changes from bar branch. I try svn status ; it's blank. I try copying over from a prestine copy of foo branch: the file now has the right content, but svn diff now shows the bar < foo diffs. svn revert again: now we've got the bar changes back. Let's try svn info :

Path: baz/qux.quux
Name: qux.quux
Working copy root path: /home/mydir/foo
URL: svn://myserver/repo/branches/foo/baz/qux.quux
Repository root: svn://myserver/repo
Repository UUID: [whatever]
Revision: 1000
Node Kind: file
Schedule: normal
Last Changed Author: [author of last change on bar, not foo]
Last Changed Rev: [rev of last change on bar, not foo]
Last Changed Date: [date of last change on bar, not foo]

So how do I get back to foo 's version of qux.quux ? And how do I clear up the "bad" state information in my working copy?

I have the feeling I'm fundamentally misunderstanding svn merge somehow.

Answer 1

It appears you want to merge by cherry-picking, which is a hack at best, in SVN . You'll need to become an svn merge expert to pull this off. Other version control systems (hg, darcs, bzr) support this method of development better , but come with their own warts. So, pick your poison and get used to it.

Answer 2

David, was using PEG-revision sensible and necessary decision? I just try to make merge as easy as possible, and ask you re-done merge from scratch with new clean Working Copy and show here all, full real commands and output (UUID isn't private data, URL of repo for test can be file:///).

Results of my test (merging heads and reverting single file) show expected results (you can re-check it on my test-case - repository is open)

• Repository Hello with some history: http://mayorat.ursinecorner.ru:8088/svn/Hello/
• Target branch Leichtbau-Deutsch: http://mayorat.ursinecorner.ru:8088/svn/Hello/branches/Leichtbau-Deutsch/
• Source branch branche-francaise: http://mayorat.ursinecorner.ru:8088/svn/Hello/branches/branche-francaise/

Steps and operations

>svn co http://mayorat.ursinecorner.ru:8088/svn/Hello/branches/Leichtbau-Deutsch/
A    Leichtbau-Deutsch\Hello.en.txt
A    Leichtbau-Deutsch\Hello.fr.txt
A    Leichtbau-Deutsch\Hello.de.txt
 U   Leichtbau-Deutsch
Checked out revision 37.

>cd Leichtbau-Deutsch

>svn merge http://mayorat.ursinecorner.ru:8088/svn/Hello/branches/branche-francaise/
--- Merging r26 through r37 into '.':
U    Hello.fr.txt
Conflict discovered in 'Z:/Leichtbau-Deutsch/Hello.de.txt'.
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: tc
U    Hello.de.txt
--- Recording mergeinfo for merge of r26 through r37 into '.':
 U   .

>svn status
 M      .
M       Hello.de.txt
M       Hello.fr.txt

>svn revert Hello.fr.txt
Reverted 'Hello.fr.txt'

>svn st
 M      .
M       Hello.de.txt

And expected result at the end

PS: I can repeat this test with PEG-revisions, if you want. But - I'll prefer use real revisions from corresponding branches and (unrelated to merge-revert) I'll have to perform (if memory serves me well) svn up (and blindly merge) to branch HEAD before be able to commit merge-set, because your svn co svn://myserver/repo/branches/foo@1000 checkout not-HEAD revision and revision history in SVN must be linear