The only log I know of is under /var/log/apache2/subversion.log,
and when I issue a checkout, I get only two lines in it:
[08/Dec/2015:09:24:53 -500] myself get-inherited-props /dev/trunk
[08/Dec/2015:09:24:53 -500] myself checkout-or-export /dev/trunk
If the error were caused by a firewall or antivirus software,
would it still make sense that the checkout begins and gets
several files in before failing? Also, to try and eliminate that
possibility, I've been performing the checkout tests on the
subversion server machine.
On 2015-12-08 05:37, Bert Huijben wrote:
you wouldn’t get ‘bad request’ errors from httpd unless
Subversion sends a bad request. Server side errors as disk
io are usually reported by other error codes, such as 500.
bad cases of status 400 are caused by firewall and antivirus
products that somehow alter requests in unexpected ways.
Another ‘expected’ case of this error is when Subversion
sends too many headers to the server; we see this in some
commits of subtrees with hundreds of locks. The
investigation for this error code should start in the server
for that too much header data, the Subversion client should
never generate a request that the server thinks is ‘bad’.
That is what it tells with status 400.
as noted before: more details should be in the server log
(and often in the response body itself… but if there was
usable data there Subversion should have noted that)
Is your repository served read-write
by other services like svnserve or eventually through
SSH in addition to Apache HTTPS access ?
If so you have to check your
repository file permissions: owner, group and modes (for
instance g+w or g+s...)
I guess your repository has been
created long ago with a previous version of Subversion.
What is your repository format
version ? Are some revisions packed ? Use svnadmin info.
Maybe you should use "svnadmin
upgrade" to get some new features properly enabled with
or even use dump/load procedure (or
svnsync) to get your repository ready (and optimized)
for Subversion 1.9.