Mojca Miklavec <mojca.miklavec.lists_at_gmail.com> 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.
Are you saying that sometimes the client gets the E175002 error without
the 'Corrupt node-revision' part?
Are you saying that the client gets the 'Corrupt node-revision' error
but it is not recorded in the error log?
> 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?
What sort of filesystem is used for the repository? Is it a local disk
or a network disk?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-01-07 17:49:09 CET