Bad interaction between merge and revert

Hija,

I've a strange (actually two related) problem(s) I can solve
in a much too complicated fashion, so I'm bringing up here for
soliciting some thoughts.

The version of subversion on server and client is 1.0.5 as
provided by Debian unstable in subversion_1.0.5-1_i386.deb.

I have three branches of one project in my repository, one
is an old imported version of the official sources, the second
is an imported version of the latest official source (which
was imported using svn_load_dirs over a shallow copy of the
old version if that matters) and my working branch.

Now I want to merge the changes between the two official
branches into my working copy. I'm using

svn merge --force URL1 URL2 WC

for this and it works like a charm except for a few annoying
things:
- The vendor checked in some smush (compiled binaries) which
   exist in my tree as well and thus causes the first merge to
   abort
- A fix of the first problem by removing the problematic files
   and a merge on the half-merged WC doesn't work because this
   is seemingly reapplying a few binary patches which break some
   other files
- To avoid this I've been do a revert before and then redid
   the merge, however the revert doesn't cleanup very well and
   leaves behind a few of the to-be-added files and directories
   which causes merge to barf with the following message unless
   I remove all the files manually:

A release/src/router/mipsel-uclibc/install/eou/usr/sbin
svn: Use --force to override this restriction
svn: 'release/src/router/mipsel-uclibc/install/eou/usr/sbin/eou' is not
under version control

   It's not only that this doesn't work but also the message is
   obviously wrong because although I supplied --force it didn't
   override the restriction.

The only way to make this work reliably is to remove the WC and
start with a completely fresh checkout which is not the way it
is recommended in the book (copy-modify-merge), a major hassle
because of SVNs slowness on big copies (for reference I just
shrunk the size of a working copy down to 780 MB, because the
2,1GB before not only took ages to process but also thrashed the
server and the clients to death a few times because of the huge
memory requirements for a commit operation), and really
time-consuming because I need to re-setup the whole compilation...

Please CC me on replies.

Servus,
       Daniel