Hi,
We've been using SVN for a couple of years, recently we migrated from 1.7.6 to
1.9.2. We also migrated (dump and load) some of the larger repositories to
schema 7 and packed them.
One of this recently migrated repositories ( SVN 1.9.2 schema 7 repository)
is about 100 GB mostly jar file
On 2015-12-08 09:09, Bert Huijben wrote:
Are you using some kind of (caching) proxy server when you connect to
the server? You are focusing your search to a disk problem (probably
caused by hints on this list), while you are trying to determine what
causes a 'bad HTTP request' error. Bad reques
On Tue, Dec 08, 2015 at 04:28:21PM +0100, Bert Huijben wrote:
> This is just the Subversion operational log generated by mod_dav_svn. The
> interesting things would be in the apache access and/or error logs.
Hi Chris,
please try raising HTTPD's LogLevel to "Debug" or higher.
See http://httpd.apa
This is just the Subversion operational log generated by mod_dav_svn. The
interesting things would be in the apache access and/or error logs.
(Depending on the configuration of your apache these could be the same logfile)
The operational log just shows successful Subversion operations, so tha
Hello,
Really your issue is strange.
I propose you test your local checkout with HTTP protocol, with a tcpdump
network traffic collection, maybe it is possible to find clues "on the
wire".
--
Yves Martin
Hi Bert.
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 r3066
[08/Dec/2015:09:24:53 -500] myself checkout-or-export /dev/trunk r3066
If the error were
I Added both these lines to the section of the Apache2
configuration file. When I do an svn checkout locally, I get the same
error occurring.
On 2015-12-08 06:09, Yves Martin wrote:
Hello,
In my Apache2 configuration, I have added "LimitRequestBody 0" and
"LimitXMLRequestBody 0" to avoid
p.s. The server is around 8 years old and has been maintained and
regularly updated, pinned to the Testing release of Debian.
On 2015-12-08 05:06, Yves Martin wrote:
I guess your repository has been created long ago with a previous
version of Subversion.
> -Original Message-
> From: Chris Capon [mailto:ttab...@gmail.com]
> Sent: dinsdag 8 december 2015 14:47
> To: users@subversion.apache.org
> Subject: Re: Unexpected HTTP status 400 'Bad request'.
>
> On 2015-12-08 05:06, Yves Martin wrote:
> > Hello
> >
> > Is your repository served r
On 2015-12-08 05:06, Yves Martin wrote:
Hello
Is your repository served read-write by other services like svnserve
or eventually through SSH in addition to Apache HTTPS access ?
I'm sorry. I don't understand what this asks. Permissions are
controlled by a .apache_auth and .apache_htpasswd
Hi Eric.
I did this:
svnadmin dump /root/subversion/root/repository > repository.dump
svnadmin create /root/subversion/root/tmprepo
chown -R www-data:www-data /root/subversion/root/tmprepo
svnadmin load /root/subversion/root/tmprepo < repository.dump
After this, I attempted a ch
Right. I also saw I have "LimitRequestFieldSize 6" set.
Is it possible for you to open a clear HTTP virtual host so that to inspect
Subversion client traffic and understand what may be wrong ?
--
Yves Martin
These are both about bodies… The headers causing that lock problem are not part
of the body.
There is probably another configuration knob for them.
Bert
From: Yves Martin [mailto:ymartin1...@gmail.com]
Sent: dinsdag 8 december 2015 12:10
To: Subversion
Subject: Re: U
Hello,
In my Apache2 configuration, I have added "LimitRequestBody 0" and
"LimitXMLRequestBody 0" to avoid such troubles with a
12-year-old-really-large repository...
Hope this helps
Regards
--
Yves Martin
Usually 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.
Most bad cases of status 400 are caused by firewall and antivirus products that
somehow alter requests in unex
Hello
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
Is it feasible to dump and load the repository in question?
You could re-load it, and see if the repository still has problems.
On the other hand, if the load fails at a specific revision, that might
give you more of a clue about what is going wrong.
Eric.
On Mon, Dec 7, 2015 at 10:13 PM, Chris
17 matches
Mail list logo
