On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote:
> Mojca Miklavec writes:
>> On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote:
>>> Mojca Miklavec writes:
>>>> Yes, there is still a problem after restarting Apache. Even though it
>>>> works for me at the moment and I tried fetching from multiple
>>>> locations and servers, other users are still experiencing the same
>>>> problem. Logs on the server confirm that. (Unable to deliver content.
>>>> [500, #0] + Could not write data to filter. [500, #175002])
>>> Does the server log always contain the error:
>>> svn: E160004: Corrupt node-revision '2-1.0.r137/330061'
>> I don't see that in the server log, but I was only checking error.log
>> written by Apache server, I don't know where else to look, but I can
>> check if you point me in the right direction. This error is sometimes
>> displayed by the "client" (either in XML in the browser or as an error
>> in the command line during "svn up"), but it's not consistent and it
>> often works properly.
> It would be in the Apache error log.
Ah, OK, I see it now in the old logs. There are no such lines in the
> Are you saying that sometimes the client gets the E175002 error without
> the 'Corrupt node-revision' part?
Yes. I'm attaching full log (with timestamps and IPs removed) for a
certain period of time around 4th January. There are plenty of E175002
errors without any subsequent 'Corrupt node-revision' part, including
all the latest entries (not part of the attachment).
> Are you saying that the client gets the 'Corrupt node-revision' error
> but it is not recorded in the error log?
I was wrong about that. I was only checking the latest error log where
all I get is
[dav:error] [pid 42289] [<IP>:29011] Unable to deliver content. [500, #0]
[dav:error] [pid 42289] [<IP>:29011] Could not write data to filter.
But I've found those additonal errors in an old (archived) log. At the
moment I'm unable to reproduce the error 'Corrupt node-revision' both
on the client and in server logs, but the repository is still
>> It sometimes works in the first attempt, fails in the second one, and
>> succeeds in the third attempt again. Only seconds or minutes apart.
>>> Is it always '2-1.0.r137/330061'?
>> The exact revision reported as currupt depends on which subfolder I'm
>> checking out. I believe it reports the last commit when files in that
>> particular subfolder were modified. (I've seen this error when
>> checking out two different subfolders. The number was always the same
>> for the same subfolder, but different for different subfolders.)
>> (It is a bit difficult to test because the behaviour is not consistent.)
> Which version of Apache are you using? Which Apache MPM are you using?
Server version: Apache/2.4.7 (Unix)
I'm not sure how to check MPM. I get
> httpd -l
Compiled in modules:
but "httpd -V" as suggested on some websites doesn't work. How should
I check which MPM is being used?
> What sort of filesystem is used for the repository? Is it a local disk
> or a network disk?
The repository is stored on a local disk. I'm not sure what about
filesystem is it that you are asking, but here are some possibly
> cat format
> cat db/fs-type
> cat db/format
layout sharded 1000
(and before I upgraded the repository, db/format was 4). Is that what
you were asking or do did you want to know something else?
Received on 2014-01-07 19:02:12 CET
- application/octet-stream attachment: error.log