On Tue, Sep 10, 2013 at 3:59 PM, Curt Sellmer <sellmer...@gmail.com> wrote: > On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn <jcor...@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 <sellmer...@gmail.com> wrote: >>> On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn <jcor...@gmail.com> wrote: >>>> On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer <sellmer...@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