The workaround for all problems of this sort is to do the legwork yourself to find the file history as detailed below.
A nice feature of Subversion is that the repository understands copies and renames, and preserves the historical connections. For example, if you copy /trunk to /branches/mybranch, then the repository understands that every file in the branch has a "predecessor" in the trunk. Running svn log --verbose will show you the historical copy, so you can see the rename, for example: r7932 | joe | 2003-12-03 17:54:02 -0600 (Wed, 03 Dec 2003) | 1 line Changed paths: A /branches /mybranch (from /trunk:7931)
Unfortunately, while the repository is aware of copies and renames, almost none of the svn client subcommands are aware. Commands like svn diff, svn merge, and svn cat don't yet understand and follow renames. This is scheduled as a post-1.0 feature. For example, if you ask svn diff to compare two earlier versions of /branches/mybranch/foo.c, the command will not automatically understand that the task actually requires comparing two versions of /trunk/foo.c, due to the rename. Instead, you'll see an error about how the branch-path doesn't exist in the earlier revisions.
You should be aware of any renamed paths, discover them yourself using svn log -v, and then provide them explicitly to the svn client. For example, instead of running $ svn diff -r 1000:2000 http://host/repos/branches/mybranch/foo.c, you would instead run $ svn diff -r1000:2000 http://host/repos/trunk/foo.c. This would avoid the message svn: Filesystem has no item svn: '/branches/mybranch/fooc..c' not found in the repository at revision 1000.