SVN commit hangs with strange log messages...

hi,
I'm administrator of a SVN-server which hosts several hundred repositories for collaborating
student groups at our university. The setup is an up-to-date CentOS 4.5 which comes with
an Apache 2.0.52. I compiled the newest Subversion RPM packages from subversion-1.4.4-0.1.rf.src.rpm
(http://dag.wieers.com/apt/) and installed it without any problem. The SVN repositories are
exclusively accessed via mod_dav_svn because we need LDAP-Authentication and don't want
to have local users. The repositories are created as FSFS repositories using Java SVNKit.

Today morning I got massive problems during the check-in of a SVN project (the check in hanged
during data transfer) and in the logs the following messages showed up.

[...]
[Thu Aug 16 02:52:28 2007] [error] [client the.client.ip.address] Unable to PUT new contents for /svn/SVNTest/!svn/wrk/5d27286c-1401-0010-a79c-9f716ebaf7f5/trunk/OnlineManager/.mymetadata. [403, #0]
[Thu Aug 16 02:52:28 2007] [error] [client the.client.ip.address] Could not prepare to write the file [500, #160012]
[Thu Aug 16 02:52:28 2007] [error] [client the.client.ip.address] Cannot write to the prototype revision file of transaction '75-1' because a previous representation is currently being written by this process [500, # 160012]
[Thu Aug 16 03:14:07 2007] [error] [client the.client.ip.address] Unable to PUT new contents for /svn/SVNTest/!svn/wrk/11bf0081-252f-4139-8d6b-444f5721cbf7/trunk/OnlineManager/WebRoot/WEB-INF/applicationContext.xml. [403, #0]
[Thu Aug 16 03:14:07 2007] [error] [client the.client.ip.address] Could not prepare to write the file [500, #160012]
[Thu Aug 16 03:14:07 2007] [error] [client the.client.ip.address] Cannot write to the prototype revision file of transaction '75-1' because a previous representation is currently being written by this process [500, #160012]
[Thu Aug 16 03:16:42 2007] [error] [client the.client.ip.address] Could not get next bucket brigade [500, #0]
[...]

Google comes up with several sites describing similar problems with fsfs repositories which claimed
to be fixed in the newest 1.4.4 release. fsfsverify didn't change the situation. Any ideas what could be
the reason for this behaviour? Every comment, idea or hint is welcome because the students are coming back
from vacation soon ;-)

Thanks,
    Gernot

P.S.: Could it be that the IPS (Intrusion Prevention System ) could just kill the connection even if the
IPS-responsable person guarantees that nothing is blocked?