[ 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
Received on 2013-09-10 20:43:04 CEST