Finally!
reported as issue 2726.
The workaround is to server-side remove the file, but the revisions
which hold the corrupted data are unusable.
My major concern is that you cannot recover that revision thus are
not able to dump or sync the repository any longer.
cu
christian unger
On 16.03.2007, at 00:40, Florent Daignière (NextGen$) wrote:
> * Florent Daignière (NextGen$) <nextgens@freenetproject.org>
> [2007-03-07 13:59:28]:
>
>> * Florent Daignière (NextGen$) <nextgens@freenetproject.org>
>> [2007-02-28 14:52:43]:
>>
>>> * John Szakmeister <john@szakmeister.net> [2007-02-28 02:56:38]:
>>>
>>>> Ph. Marek wrote:
>>>>> On Wednesday 28 February 2007 07:03, Malcolm Rowe wrote:
>>>>> ...
>>>>>> So I'm thinking that somewhere in #3, the APR file buffer is
>>>>>> written
>>>>>> twice. I can think of only a few ways to achieve that effect,
>>>>>> and none
>>>>>> of them seem particularly likely:
>>>>> ...
>>>>>
>>>>> If that's repeatable and on a platform allowing for API traces
>>>>> (see eg.
>>>>> strace on linux -- similar things exist for other OS), that
>>>>> could help a
>>>>> lot - it would tell us the sequence of events.
>>>>
>>>> That's been a huge problem. Only 1 user has ever been able to
>>>> repeat
>>>> the problem (and he no longer can). Even then it was only after an
>>>> undetermined series of commits. I've spent hours and hours
>>>> trying...
>>>> and have had no luck.
>>>>
>>>> -John
>>>
>>> I doubt I will be able to reproduce it : In spite I kept both the
>>> working
>>> copy and the directory containing the repository, I haven't
>>> managed to
>>> so far...
>>>
>>> Moreover, I have done a dump/load of the repository up to latest
>>> working
>>> version and sucessfully commited the *same* patch using the *same*
>>> client software.
>>>
>>> NextGen$
>>
>> Someone reproduced it yesterday on the same repository (same server,
>> same version of apache-mpm-worker, same client software : subclipse
>> 1.0.3 : an old version of javaSVN) attempting to commit a different
>> patch from a different working copy.
>>
>> I have enclosed the revision file to this mail in case it helps
>> and will
>> ask our commiters to update their client software.
>>
>> NextGen$
>
> Today I have encountered an other problem with the same repository :
> on revision 12150 svnlook (started from the post-commit hook)
> complained about :
> "svnlook: Decompression of svndiff data failed"
> http://archives.freenetproject.org/message/
> 20070315.215906.f3661837.en.html
>
> Then I managed to commit r12151 sucessfully, and svnlook managed to do
> its job on it for some time ; a commit mail got genarated !
> http://archives.freenetproject.org/message/
> 20070315.221857.0d594b69.en.html
>
> and since then I can't access the repository anymore... errors and
> symptoms
> are different from last time... but the result is the same : the
> repository
> is unavailable. The client software has been updated to subclipse
> 1.2.0 in
> the meantime.
>
> Apache's logs report :
> [Thu Mar 15 22:23:21 2007] [error] [client 208.181.82.58] Provider
> encountered an error while streaming a REPORT response. [500, #0]
> [Thu Mar 15 22:23:21 2007] [error] [client 208.181.82.58] A failure
> occurred while driving the update report editor [500, #185005]
> [Thu Mar 15 22:23:21 2007] [error] [client 208.181.82.58]
> Decompression of svndiff data failed [500, #185005]
>
> Here are links to revision files in case it helps:
> http://emu.freenetproject.org/~nextgens/12150
> http://emu.freenetproject.org/~nextgens/12151
>
> Apache and mod_dav_svn are the only frontend configured.
>
> nextgens@emu:~$ svn --version|head -1
> svn, version 1.4.2 (r22196)
> nextgens@emu:~$ svnlook --version|head -1
> svnlook, version 1.4.2 (r22196)
> nextgens@emu:~$ svnadmin --version|head -1
> svnadmin, version 1.4.2 (r22196)
> nextgens@emu:~$ dpkg -l libapache2-svn |grep ii
> ii libapache2-svn 1.4.2dfsg1-2 Subversion server modules for Apache
> nextgens@emu:~$ dpkg -l apache2-mpm-* |grep ii
> ii apache2-mpm-worker 2.2.3-3.3 High speed threaded model
> for Apache HTTPD 2
>
> SMART doesn't report any hard-drive error (I know that's not a
> proof it's
> not faulty) and the server has 98 days of uptime... There is no
> obvious
> kernel oops in logs nor complain about filesystem corruption...
>
> I wonder if I'm really (un)lucky or if the hardware is to blame.
>
> NextGen$
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 16 08:37:23 2007