# Get a fresh working copy of the above
svn co file:///$(pwd)/bug_deldir.repos/test
A test/dir
Checked out revision 2.

# Now the game begin
cd test

# Remove (accidentally) a directory under svn's control
rm -rf dir

# Ask 'svn' and get the information, that you messed with the contents

svn st
! dir

# Okay back-up and check if all is like before ...

svn revert .
svn st
! dir

# 'svn revert' didn't work as was to be expected by documentation!
# So take 'svn update' now and check again:

svn update .
A dir
Updated to revision 2.
svn st

# Yay! All okay, as I never did anything wrong ... :-)
# Now I think, I will schedule 'dir' to be removed from svn's control
# Do not forget to check the outcome ...

svn delete dir
D dir
svn st
D dir

# Nice! All as I have expected. But now I change my mind and 'revert'
# the scheduled deletion. Do not forget to check what svn things about

svn revert dir
Reverted 'dir'
svn st

# Okay 'svn st' did not find any modification. All as it was before.
# Now do the same mistake done before. Remove 'dir' without scheduling
# any deletion that time. Do not miss to check, what svn things about

In summary, if I remove a directory that is under Subversion's control
without scheduleing a deletion before, Subversion will report it and
deny to commit the mess I did!

But only as long as I *never* did schedule said directory to be deleted
any time in the past of my working copy. If I did (and reverted that
deletion before commit), any subsequent physical remove of the directory
will result into a auto-scheduled deletion that will be committed too if
I did not pay attention to the output!

I think, that is a bug, as it is different for deleted-and-then-reverted
files that behave as I would expect.