Re: Error during 'svn export' over http with serf 1.3.1
That thought had crossed my mind, but so far none of the other users who are still using 1.7 clients have had any issues and also running the 1.8.1 client on the server box using the file:// scheme has never produced an error. On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser b...@reser.org wrote: On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer sellmer...@gmail.com wrote: That thought had crossed my mind, but so far none of the other users who are still using 1.7 clients have had any issues and also running the 1.8.1 client on the server box using the file:// scheme has never produced an error. On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser b...@reser.org wrote: On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing. I installed client version 1.7.11 and I do occasionally get an error when accessing a repo with db format 6. $ svn log http://gemini2/svn/www/branches svn: E175002: REPORT of '/svn/www/!svn/rvr/496/branches': Could not read chunk size: connection was closed by server (http://gemini2) running this against the repo with db format 4 does not cause the problem with 1.7.11. I have seen the decompression problem using 1.8.3 against the format 4 repo. I have still never seen a problem when running locally using the file:// scheme and I have repeated the command many many times. This indicates that the repo is ok and the problem has to do with serving the data over http://. Using: 1.8.3 client (serf 1.3.1) Connecting to: repo with db format 6 (I dumped and loaded the format 4 repo to a new format 6 again) Seems the path is significant in what errors I receive. $ svn log http://gemini2/svn/www Ran this command 50 times with no errors. $ svn log http://gemini2/svn/www/trunk Ran this 50 times and got the following error 5 times. Interesting to note that commit 496 was made on a branch. svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/www/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/www/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '496 2752 110 0 8733d74a90f550a19dddad89a54718fa' $ svn log http://gemini2/svn/www/branches Ran this 15 times and got the following error 12 times. svn: E120104: ra_serf: An error occurred during decompression
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer sellmer...@gmail.com wrote: That thought had crossed my mind, but so far none of the other users who are still using 1.7 clients have had any issues and also running the 1.8.1 client on the server box using the file:// scheme has never produced an error. On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser b...@reser.org wrote: On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing. I installed client version 1.7.11 and I do occasionally get an error when accessing a repo with db format 6. $ svn log http://gemini2/svn/www/branches svn: E175002: REPORT of '/svn/www/!svn/rvr/496/branches': Could not read chunk size: connection was closed by server (http://gemini2) running this against the repo with db format 4 does not cause the problem with 1.7.11. I have seen the decompression problem using 1.8.3 against the format 4 repo. I have still never seen a problem when running locally using the file:// scheme and I have repeated the command many many times. This indicates that the repo is ok and the problem has to do with serving the data over http://.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 12:17 PM, Lieven Govaerts lieven.govae...@gmail.com wrote: On Wed, Sep 11, 2013 at 6:26 PM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer sellmer...@gmail.com wrote: That thought had crossed my mind, but so far none of the other users who are still using 1.7 clients have had any issues and also running the 1.8.1 client on the server box using the file:// scheme has never produced an error. On Wed, Sep 11, 2013 at 2:32 AM, Ben Reser b...@reser.org wrote: On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the svn: E120104: ra_serf: An error occurred during decompression error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' Are you sure the server end is ok? Those errors are signs of a corrupted repository. I'm starting to wonder if you're not having issues due to a hardware issue on the server side. Failing memory could explain the behavior you're seeing. I installed client version 1.7.11 and I do occasionally get an error when accessing a repo with db format 6. $ svn log http://gemini2/svn/www/branches svn: E175002: REPORT of '/svn/www/!svn/rvr/496/branches': Could not read chunk size: connection was closed by server (http://gemini2) running this against the repo with db format 4 does not cause the problem with 1.7.11. I have seen the decompression problem using 1.8.3 against the format 4 repo. I have still never seen a problem when running locally using the file:// scheme and I have repeated the command many many times. This indicates that the repo is ok and the problem has to do with serving the data over http://. Using: 1.8.3 client (serf 1.3.1) Connecting to: repo with db format 6 (I dumped and loaded the format 4 repo to a new format 6 again) Seems the path is significant in what errors I receive. $ svn log http://gemini2/svn/www Ran this command 50 times with no errors. $ svn log http://gemini2/svn/www/trunk Ran this 50 times and got the following error 5 times. Interesting to note that commit 496 was made on a branch. svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/www/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/www/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '496 2752 110 0 8733d74a90f550a19dddad89a54718fa' The origin of these two errors is server side, they are only reported on the client. Do you see anything special in the server access and error logs? We have seen a case were http headers were dropped (by a virus scanner) leading to strange requests. $ svn log http://gemini2/svn/www/branches Ran this 15 times and got the following error 12 times. svn: E120104: ra_serf: An error occurred during decompression I suppose these are similar to other reports already under investigation (and I can reproduce myself), so let's focus on the server errors here. Lieven Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. [Wed Sep 11 11:24:42.592421 2013] [dav:error] [pid 5918] [client 192.168.0.139:53889] Provider encountered an error while streaming a REPORT response
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 3:04 PM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors. Here is a new one. Running 1.8.3 client against 1.8.1 server. repo is format 4. svnadmin verity reports no problems. $ svn ls http://gemini2/svn/roclock/trunk svn: E24: Could not convert '###error###' into a number error.log on server logs this: [Wed Sep 11 18:40:14.393500 2013] [:error] [pid 14479] (160004)APR does not understand this error code: [client 192.168.0.139:55525] Can't fetch proplist of '/trunk': Corrupt representation '137 5727 30 0 bccc4074133de2a54dfaee6dfacbfede' Now when I run my 1.7.11 client against the same repo it works fine. This is reproducible every time. I created a new repo (format 6) dumped/loaded. The 1.8.3 client works fine against the new repo.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin philip.mar...@wandisco.com wrote: Curt Sellmer sellmer...@gmail.com writes: On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors. You said you dumped and loaded your repository. You also have corruption shown by apache that is not shown by svnadmin. When you dump/load are you also putting the new repository in the same place as the old repository? If so, are you restarting apache? It's perfectly acceptable to replace a repository but you must restart apache if the repository is altered but the UUID is not changed. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* In this case I created a new repo using a different name. I left the old one intact. Then just referenced the new repo's url. In the last few days, thought I have moved the old repo to A.orig then moved the new repo to A. I did not know of the requirement to restart apache. Will do that going forward. Thanks.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 7:04 PM, Curt Sellmer sellmer...@gmail.com wrote: On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin philip.mar...@wandisco.com wrote: Curt Sellmer sellmer...@gmail.com writes: On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser b...@reser.org wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. I just ran svnadmin verify on the repo again and still it does not report any errors. You said you dumped and loaded your repository. You also have corruption shown by apache that is not shown by svnadmin. When you dump/load are you also putting the new repository in the same place as the old repository? If so, are you restarting apache? It's perfectly acceptable to replace a repository but you must restart apache if the repository is altered but the UUID is not changed. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* In this case I created a new repo using a different name. I left the old one intact. Then just referenced the new repo's url. In the last few days, thought I have moved the old repo to A.orig then moved the new repo to A. I did not know of the requirement to restart apache. Will do that going forward. Thanks. I just bounced the apache server and it did indeed clear up the problem. I can now access the repo with both clients. Thank you. I apologize that I didn't realize that the web server had to be bounced. Not sure that was in the docs anywhere? This may well be the cause of the previous problems as I had a script that would create a new repo, dump | load to it, then rename the new repo with the original repo's name. I'll keep testing with the new found knowledge.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 7:19 PM, Curt Sellmer sellmer...@gmail.com wrote: You said you dumped and loaded your repository. You also have corruption shown by apache that is not shown by svnadmin. When you dump/load are you also putting the new repository in the same place as the old repository? If so, are you restarting apache? It's perfectly acceptable to replace a repository but you must restart apache if the repository is altered but the UUID is not changed. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* In this case I created a new repo using a different name. I left the old one intact. Then just referenced the new repo's url. In the last few days, thought I have moved the old repo to A.orig then moved the new repo to A. I did not know of the requirement to restart apache. Will do that going forward. Thanks. I just bounced the apache server and it did indeed clear up the problem. I can now access the repo with both clients. Thank you. I apologize that I didn't realize that the web server had to be bounced. Not sure that was in the docs anywhere? This may well be the cause of the previous problems as I had a script that would create a new repo, dump | load to it, then rename the new repo with the original repo's name. I'll keep testing with the new found knowledge. Since bouncing the apache server I am not seeing any errors with any of the repos. Classic case of user error. I really appreciate all of your help and quick responses. Thanks, Curt
Re: Error during 'svn export' over http with serf 1.3.1
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
Re: Error during 'svn export' over http with serf 1.3.1
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
Re: Error during 'svn export' over http with serf 1.3.1
) - /usr/lib/libobjc.A.dylib (Intel 64-bit) - /usr/lib/libauto.dylib (Intel 64-bit) - /usr/lib/libc++abi.dylib (Intel 64-bit) - /usr/lib/libc++.1.dylib (Intel 64-bit) - /usr/lib/libDiagnosticMessagesClient.dylib (Intel 64-bit) - /usr/lib/libcrypto.0.9.8.dylib (Intel 64-bit) - /usr/lib/libssl.0.9.8.dylib (Intel 64-bit) - /usr/lib/libresolv.9.dylib (Intel 64-bit) - /usr/lib/libicucore.A.dylib (Intel 64-bit) - /usr/lib/libstdc++.6.dylib (Intel 64-bit) - /usr/lib/libbsm.0.dylib (Intel 64-bit) - /usr/lib/libxar.1.dylib (Intel 64-bit) - /usr/lib/libpam.2.dylib (Intel 64-bit) - /usr/lib/libOpenScriptingUtil.dylib (Intel 64-bit) - /usr/lib/libbz2.1.0.dylib (Intel 64-bit) - /usr/lib/libxml2.2.dylib (Intel 64-bit) - /usr/lib/liblangid.dylib (Intel 64-bit) - /usr/lib/libCRFSuite.dylib (Intel 64-bit) - /usr/lib/libxslt.1.dylib (Intel 64-bit) - /usr/lib/sasl2/apop.so (Intel 64-bit) - /usr/lib/sasl2/dhx.so (Intel 64-bit) - /usr/lib/sasl2/digestmd5WebDAV.so (Intel 64-bit) - /usr/lib/sasl2/libanonymous.2.so (Intel 64-bit) - /usr/lib/sasl2/libcrammd5.2.so (Intel 64-bit) - /usr/lib/sasl2/libdigestmd5.2.so (Intel 64-bit) - /usr/lib/sasl2/libgssapiv2.2.so (Intel 64-bit) - /usr/lib/sasl2/login.so (Intel 64-bit) - /usr/lib/sasl2/libntlm.so (Intel 64-bit) - /usr/lib/sasl2/libotp.2.so (Intel 64-bit) - /usr/lib/sasl2/libplain.2.so (Intel 64-bit) - /usr/lib/sasl2/libpps.so (Intel 64-bit) - /usr/lib/sasl2/mschapv2.so (Intel 64-bit) - /usr/lib/sasl2/pwauxprop.so (Intel 64-bit) - /usr/lib/sasl2/shadow_auxprop.so (Intel 64-bit) - /usr/lib/sasl2/smb_nt.so (Intel 64-bit) - /usr/lib/sasl2/smb_ntlmv2.so (Intel 64-bit) On Wed, Sep 11, 2013 at 12:32 AM, Curt Sellmer sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 8:39 PM, Ben Reser b...@reser.org wrote: On 9/10/13 2:31 PM, Curt Sellmer wrote: 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. Can you please post the output of: svn --version --verbose If that command doesn't show that you're using serf 1.3.1 can you please rebuild using the 1.3.1 version of the serf library? The minimum required serf version is still 1.2.1 in 1.8.0-1.8.3. Serf 1.3.0 and 1.3.1 have fixed quite a few bugs that impact Subversion users, but they also switched to using the SCons build system that may present some trouble for people building. Since most of the issues fixed in serf are relatively rare we haven't raised the minimum required version. If after you've upgraded serf to 1.3.1 and if you are still having the issue it could still either be a bug in Subversion or a bug in Serf. It is indeed serf 1.2.1 installed via homebrew. Homebrew does not yet have 1.3.1 due to the SCons issue that you mentioned. I will try to download and build serf 1.3.1. Here is the output of svn --version --verbose 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
