bug report - merge delete error

I posted the following bug report to dev at tortoisesvn.tigris.org. Simon
responded, instructing me to repost it here. (He said that it sounded like
a problem with the underlying svn library.)

----
I'm using TortoiseSVN v1.4.8 on a Ruby-on-Rails project.  The repository is
hosted by CVSDude.com, an Australian company that specializes in source-code
hosting.  My working copy reflects HEAD of a branch.  To merge in changes
from /trunk, I had tsvn compute the change-set between the last-merged
revision and the latest /trunk and apply it to the working copy of the
branch.  This appears to succeed.
After resolving conflicts, I commit the branch back to the repository.  The
commit processes through to the end but then I get three error messages:
 - Commit succeeded, but other errors follow:
 - Error bumping revisions post-commit (details follow):
 - Directory
'#{working-copy-root}\vendor\plugins\acts_as_authenticated\generators\authenticated_migration'
is missing
I found
'vendor\plugins\acts_as_authenticated\generators\authenticated_migration' in
the tsvn commit activity listing.  It was listed with action "Deleting".
Then the working copy is rendered unrecoverably unusable.  Update fails
claiming that the top-level directory in the working-copy is locked and that
I have to run 'cleanup'.  Cleanup fails with a pop-up box claiming:
{{{
Subversion reported an error while doing a cleanup!
----
In directory
'#{working-copy-root}\vendor\plugins\acts_as_authenticated\generators'
Error processing commend 'committed' in
'#{working-copy-root}\vendor\plugins\acts_as_authenticated\generators'
Working copy
'#{working-copy-root}\vendor\plugins\acts_as_authenticated' locked
}}}
I went to 'vendor\plugins' and noticed that some of the other changes
produced by the merge are not marked as committed but the changes to
'vendor\plugins\acts_as_authenticated' are all represented correctly by the
shell-integrated tsvn UI.
Then I checked-out a fresh working copy.  On first glance, it represents all
files in the appropriate state.
The revision-number-bumping error actually seems to be reproducible.  I've
done this merge once before, a little differently.  Before the merge attempt
described above, I had the branch with trunk merged-in but not committed
sitting around for over a week.  I committed the changes and performed
another merge over the more-recently committed work in trunk.  On the commit
of the second merge, my working copy was rendered unusable and the committed
result was actually missing some of the files from trunk (which I discovered
when I did a dry-run merge of the updated branch back into trunk and saw
some inappropriate deletes).  At that point, it looked like everything had
gone haywire.  I deleted the post-merge branch and copied the pre-merge
branch revision up to HEAD so I could try again.
I have just started the merge-back into trunk and have encountered some
unusual difficulties.  I will post a reply to this report if my pending
merge (of the updated branch back to into trunk) yields any new information.
_james schneider