On 12/7/2015 2:56 PM, Chris Capon wrote:
Hi.
We are running a Subversion server using Apache2 2.4.17-3, modDAV, and
Subversion 1.9.2-3+b1 (the latest Testing release) under Debian
GNU/Linux. We use HTTPS for security along with client certificates.
This server has been running for many years with the same configuration.
A week or so ago, when trying to commit to ONE of the repositories on
this server, from a long-time client Windows machine running
TortoiseSVN 1.9.2, Build 26806, the commit failed with the error:
Unexpected HTTP status 400 'Bad request' on .... {one of the files}
Since then, we have not been able to commit anything to that
repository. On a commit with about 6 files, it seems to fail on
different files periodically. It isn't always the same file name in
the error message.
The thing is, we can still do commits to other repositories on the
same server and folder tree without this error happening and even from
the same Windows machine. So I don't think the communications
themselves are the problem. There is no hardware firewall between the
client and the server.
To diagnose the problem, I tried to check out the repository on the
subversion server itself to a local folder (hoping to eliminate the
network as the problem). When I execute:
svn checkout https://server/svn/repository/dev/trunk --username
myself dev
the checkout begins to download files then will randomly stop after
about 10 files with this error:
svn: E175013: Access to 'filename' forbidden.
Repeating the experiment will cause it to fail at different files
seemingly randomly. Trying to 'svn cleanup' and 'svn update' the
partially checked out folder will give the same error after bringing
down a few more files.
I have made sure permissions are set correctly for the Apache user in
the folder with the subversion repository.
None of the log files under /var/log/apache2 seem to catch or record
anything about the errors, nor is there anything in the subversion.log
file in the same folder. I am not sure how to capture the cause of
the error on the server side.
Can anyone help me diagnose this problem?
Thanks.
Have you verified that the repository on the server is not corrupt?
Perhaps the disk has a bad sector on the drive, and only that repository
is affected. Or maybe the hard drive itself is failing, and the other
repositories have simply been "lucky" so far.
# svnadmin verify /path/to/repository/root
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
