On Tue, Sep 10, 2013 at 3:59 PM, Curt Sellmer <sellmerfud_at_gmail.com> wrote:
> On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> [ Please use reply all to keep the list in the loop -- I'm sending
>> this to users@ rather than dev@, because other users might also be
>> interested and/or can chime in if someone has similar issues.
>> Also, this list prefers bottom-posting or inline replying, so I've
>> rearranged to put your reply at the bottom. More below. ]
>>
>> On Tue, Sep 10, 2013 at 4:47 PM, Curt Sellmer <sellmerfud_at_gmail.com> wrote:
>>> On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>>> On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer <sellmerfud_at_gmail.com> wrote:
>>>>> On Sun, Aug 25, 2013 at 1:41 AM, Lieven Govaerts
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> On Sun, Aug 25, 2013 at 1:36 AM, Johan Corveleyn <[hidden email]> wrote:
>> ...
>>>>>> FYI: another user has reported seeing the same error message (during a
>>>>>> reintegrate merge ... not sure if it's the same issue, but the error
>>>>>> is the same at least):
>>>>>
>>>>>> http://svn.haxx.se/users/archive-2013-09/0070.shtml
>>>>>
>>>>> I came across this error message today as well. I recently upgraded
>>>>> my svn server to 1.8.1. I have been dumping my repos and loading them
>>>>> into new repos.
>>>>> On one particular repo, I get this error when doing the following command:
>>>>>
>>>>> svn log -l 4 http://server/repo/branches
>>>>>
>>>>> I get the error about 50% of the time. Interestingly when I run the
>>>>> same command against http://server/repo/trunk I never get the error.
>>>>>
>>>>> I tried disabling compression with --config-option
>>>>> servers:global:http-compression=off and when I do this about 50% of
>>>>> the time I get only the first two log entries. But no error is
>>>>> reported.
>>>>>
>>>>> So far I've only noticed the problem on one repo. I even did the
>>>>> dump/load a second time an the results are the same.
>>>>
>>>> What's your client version? Can you show the output of svn --version
>>>> of the client?
>>>>
>>> Here is version output from my dev box
>>> svn --version
>>> svn, version 1.8.0 (r1490375)
>>> compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0
>>>
>>> Copyright (C) 2013 The Apache Software Foundation.
>>> This software consists of contributions made by many people;
>>> see the NOTICE file for more information.
>>> Subversion is open source software, see http://subversion.apache.org/
>>>
>>> The following repository access (RA) modules are available:
>>>
>>> * ra_svn : Module for accessing a repository using the svn network protocol.
>>> - with Cyrus SASL authentication
>>> - handles 'svn' scheme
>>> * ra_local : Module for accessing a repository on local disk.
>>> - handles 'file' scheme
>>> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
>>> - handles 'http' scheme
>>> - handles 'https' scheme
>>>
>>> ----------------
>>> I am also seeing the problem when I run the command on the server box
>>> itself and using
>>> the 'http' scheme. Here is svn --version for that:
>>>
>>> svn, version 1.8.1 (r1503906)
>>> compiled Jul 24 2013, 11:57:22 on i686-pc-linux-gnu
>>>
>>> Copyright (C) 2013 The Apache Software Foundation.
>>> This software consists of contributions made by many people;
>>> see the NOTICE file for more information.
>>> Subversion is open source software, see http://subversion.apache.org/
>>>
>>> The following repository access (RA) modules are available:
>>>
>>> * ra_svn : Module for accessing a repository using the svn network protocol.
>>> - handles 'svn' scheme
>>> * ra_local : Module for accessing a repository on local disk.
>>> - handles 'file' scheme
>>> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
>>> - handles 'http' scheme
>>> - handles 'https' scheme
>>>
>>> --------------
>>> Problem does not occur when using the 'file' scheme which makes sense.
>>
>> First thing to try is to test this with the latest client release,
>> 1.8.3 (this uses serf 1.3.1 internally). A lot of connection-related
>> bugs have been fixed already [1].
>>
>>> I have seen each of the following results when running the same command:
>>>
>>> svn: E120104: ra_serf: An error occurred during decompression
>>> svn: E160004: Corrupt representation '489 681 46 46 a2a7fa5ef17fb3ca
>>> svn: E070014: Can't read file
>>> '/opt/local/csvn/data/repositories/www/db/revs/0/489': End of file
>>> found
>>> And sometimes the command works successfully.
>>>
>>> Running svnadmin verify on the repo shows no problems.
>>
>> Hmm, that seems something different than what I'm seeing. In my case,
>> I just got the decompression error, but no reference to a corrupt
>> representation or a corrupt rev file.
>>
>> Are you sure that you can't reproduce this when executing the exact
>> same command with file:// (which should read the same rev file)? And
>> the error doesn't reproduce always, but only some of the time?
>>
>>> I can reproduce this with several repos created by the new version
>>> 1.8.1 on the server.
>>> But other new repos do not cause it to happen. So far all of the
>>> existing repos do not
>>> cause the problem to occur.
>>> Format number from repo/db/format is 4 for existing and 6 for new repos.
>>>
>>> Hope this helps.
>>
>> Strange. As I said, first try with a 1.8.3 client, and see if it
>> reproduces. Then, perhaps you can also update your server to 1.8.3,
>> just to be sure that you're not chasing something that has already
>> been fixed (and double-check 'svnadmin verify' with the latest server
>> release).
>>
>> [1] http://svn.apache.org/repos/asf/subversion/tags/1.8.3/CHANGES
>>
>> --
>> Johan
>
> Well, I just got some time to look into this again and I cannot get
> the command to fail at this time with 1.8.0. The sporadic nature of
> it is quite frustrating. Perhaps because there is less network
> traffic at the office at this time?
>
> I have downloaded and compiled version 1.8.3 on my dev box. So when
> the problem surfaces again I will be able to see if there is different
> behavior between the two.
>
> Curt
After giving it more time I can now reproduce the problem with both
version 1.8.0 and 1.8.3 of the client. And I have now seen the
problem with both the older and newer versions of the repository.
Very hard to debug as it does not seem to follow any pattern. As I
posted earlier, it was working without a hitch for several minutes of
testing. Then I went through a period where it failed more than
succeeded. A bit later it was failing more sporadically, regardless
of which version of the client.
I can say this with complete confidence, but it seems that the 1.8.3
client fails more with the old repo and the 1.8.0 client fails more
with the new repo, but I can verify that the both have failed with
both repos.
With 1.8.0 I see the following errors (separate runs):
svn: E160004: Corrupt node-revision '3-1.0-489.r495/2100'
svn: E120104: ra_serf: An error occurred during decompression
------------
With 1.8.3 I get the same errors but the reporting for the Corrupt
node is different:
svn: E175002: Unexpected HTTP status 400 'Bad Request' on
'/svn/www/!svn/rvr/496/branches/rails-3.2'
svn: E160004: Additional errors:
svn: E160004: Corrupt node-revision '3-1.0-489.r495/2100'
And again both errors can be seen against both repos.
I ran svnadmin verify again against both repos with no errors reported.
Curt
Received on 2013-09-10 23:32:03 CEST