Interesting use case of svn renames

This is an interesting use case which has left development kind of broken at
where I work and I hope someone can help me.

User A was working on a file foo in the trunk. He wanted to edit this file,
but since many others used this file, he wrongly decided, to rename this
file to bar and then create a new file foo with the contents of bar (and few
of his changes) and add it to revision control

svn mv foo bar
touch foo #edit foo, add contents of bar to foo
svn add foo

Next, User B working on a branch, unaware of the changes on the trunk,
decided to merge changes from the trunk into his branch. Naturally, the
add's and deletes followed. But he was OK with it because he wasn't working
on this particular file. The logs do show an 'R' against the original foo
file, showing that it was replaced by the new file bar.

Now, when it came for the time for him to re-integrate his branch into the
trunk - he ran the merge command from the exact directory(not the top level
of the working copy) in which these renamed files reside and he got this
error

svn: Working copy path 'path-to-the-bar-file' does not exist in repository

Now, User B finds he cannot merge his work back in. What should he do?

1. Does completely removing the questionable file and re-adding it help?
2. Blocking the revision in which the rename happened won't help because it
was coupled with few other changes.

What can User B do?

-- 
View this message in context: http://www.nabble.com/Interesting-use-case-of-svn-renames-tp19090042p19090042.html
Sent from the Subversion Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org