This only happened once, and I haven't yet attempted to reproduce it
under controlled conditions. Nevertheless, here is a recipe based on
the working copy and repository I had at the time:
1. svn co http://svn.collab.net/repos/svn/trunk -d svn
2. cd svn/tools/hook-scripts
3. touch verify-log-msg.sh (i.e., create a new, unversioned file here)
4. modify commit-email.pl (I had changed only one line)
5. Put a few lines of content in ../../msg (my accumulating log msg)
At this point, there should be nothing in ./SVN/auth/, so that when you
to commit, you get prompted for auth information.
Also, in the repository, there is a broken pre-commit script that always
exits with code 1, so all commits fail due to pre-commit check failure.
6. svn ci -F ../../msg
The commit fails, but SVN/text-base/commit-email.pl is now the same as the
working file, which is changed w.r.t. the repository! Thus, subversion can
no longer detect locally that you have changed the file, and has wrong
contents for the claimed revision. Your working copy is corrupt. Go home.
Blocker