You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2013/09/10 20:42:09 UTC
Re: Error during 'svn export' over http with serf 1.3.1
[ 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 <se...@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer <se...@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
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Curt Sellmer <se...@gmail.com>.
On Wed, Sep 11, 2013 at 3:04 PM, Curt Sellmer <se...@gmail.com> wrote:
> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser <be...@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: E200004: 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
Posted by Curt Sellmer <se...@gmail.com>.
On Wed, Sep 11, 2013 at 7:19 PM, Curt Sellmer <se...@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
Posted by Curt Sellmer <se...@gmail.com>.
On Wed, Sep 11, 2013 at 7:04 PM, Curt Sellmer <se...@gmail.com> wrote:
> On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Curt Sellmer <se...@gmail.com> writes:
>>
>>> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser <be...@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
Posted by Curt Sellmer <se...@gmail.com>.
On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Curt Sellmer <se...@gmail.com> writes:
>
>> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser <be...@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
Posted by Philip Martin <ph...@wandisco.com>.
Curt Sellmer <se...@gmail.com> writes:
> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser <be...@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*
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Curt Sellmer <se...@gmail.com>.
On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser <be...@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
Posted by Ben Reser <be...@reser.org>.
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.
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Curt Sellmer <se...@gmail.com>.
On Wed, Sep 11, 2013 at 12:17 PM, Lieven Govaerts
<li...@gmail.com> wrote:
> On Wed, Sep 11, 2013 at 6:26 PM, Curt Sellmer <se...@gmail.com> wrote:
>> On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer <se...@gmail.com> wrote:
>>> On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer <se...@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 <be...@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. [400, #0]
[Wed Sep 11 11:24:42.592445 2013] [dav:error] [pid 5918] [client
192.168.0.139:53889] Corrupt node-revision '2-1.0.r491/2477' [400,
#160004]
[Wed Sep 11 11:24:42.592452 2013] [dav:error] [pid 5918] [client
192.168.0.139:53889] Corrupt node-revision '2-1.0.r491/2477' [400,
#160004]
[Wed Sep 11 11:24:42.592457 2013] [dav:error] [pid 5918] [client
192.168.0.139:53889] Missing id field in node-rev [400, #160004]
[Wed Sep 11 11:24:44.100718 2013] [dav:error] [pid 10814] [client
192.168.0.139:53891] Provider encountered an error while streaming a
REPORT response. [400, #0]
[Wed Sep 11 11:24:44.100745 2013] [dav:error] [pid 10814] [client
192.168.0.139:53891] Corrupt representation '417 26025 111 111
efae71eb2827965140f7f6208f62b720' [400, #160004]
[Wed Sep 11 11:24:44.100753 2013] [dav:error] [pid 10814] [client
192.168.0.139:53891] Corrupt representation '417 26025 111 111
efae71eb2827965140f7f6208f62b720' [400, #160004]
[Wed Sep 11 11:24:44.100758 2013] [dav:error] [pid 10814] [client
192.168.0.139:53891] Malformed representation header at
/opt/local/csvn/data/repositories/www/db/revs/0/417:26066 [400,
#160004]
[Wed Sep 11 11:24:46.228949 2013] [dav:error] [pid 5914] [client
192.168.0.139:53893] Provider encountered an error while streaming a
REPORT response. [400, #0]
[Wed Sep 11 11:24:46.228975 2013] [dav:error] [pid 5914] [client
192.168.0.139:53893] Corrupt node-revision '2-1.0.r428/10497' [400,
#160004]
[Wed Sep 11 11:24:46.228982 2013] [dav:error] [pid 5914] [client
192.168.0.139:53893] Corrupt node-revision '2-1.0.r428/10497' [400,
#160004]
[Wed Sep 11 11:24:46.228987 2013] [dav:error] [pid 5914] [client
192.168.0.139:53893] Found malformed header '8/10484' in revision file
[400, #160004]
[Wed Sep 11 11:24:47.016169 2013] [dav:error] [pid 11160] [client
192.168.0.139:53894] Provider encountered an error while streaming a
REPORT response. [400, #0]
[Wed Sep 11 11:24:47.016194 2013] [dav:error] [pid 11160] [client
192.168.0.139:53894] Corrupt node-revision '2-1.0.r494/2125' [400,
#160004]
[Wed Sep 11 11:24:47.016201 2013] [dav:error] [pid 11160] [client
192.168.0.139:53894] Corrupt node-revision '2-1.0.r494/2125' [400,
#160004]
[Wed Sep 11 11:24:47.016206 2013] [dav:error] [pid 11160] [client
192.168.0.139:53894] Found malformed header 'P' in revision file
[400, #160004]
[Wed Sep 11 11:24:47.805664 2013] [dav:error] [pid 5927] [client
192.168.0.139:53895] Provider encountered an error while streaming a
REPORT response. [400, #0]
[Wed Sep 11 11:24:47.805748 2013] [dav:error] [pid 5927] [client
192.168.0.139:53895] Corrupt node-revision '2-1.0.r428/10497' [400,
#160004]
[Wed Sep 11 11:24:47.805779 2013] [dav:error] [pid 5927] [client
192.168.0.139:53895] Corrupt node-revision '2-1.0.r428/10497' [400,
#160004]
[Wed Sep 11 11:24:47.805805 2013] [dav:error] [pid 5927] [client
192.168.0.139:53895] Found malformed header '8/10484' in revision file
[400, #160004]
[Wed Sep 11 11:24:48.634131 2013] [dav:error] [pid 10816] [client
192.168.0.139:53896] Provider encountered an error while streaming a
REPORT response. [400, #0]
[Wed Sep 11 11:24:48.634216 2013] [dav:error] [pid 10816] [client
192.168.0.139:53896] Corrupt representation '417 26025 111 111
efae71eb2827965140f7f6208f62b720' [400, #160004]
[Wed Sep 11 11:24:48.634247 2013] [dav:error] [pid 10816] [client
192.168.0.139:53896] Corrupt representation '417 26025 111 111
efae71eb2827965140f7f6208f62b720' [400, #160004]
[Wed Sep 11 11:24:48.634274 2013] [dav:error] [pid 10816] [client
192.168.0.139:53896] Malformed representation header at
/opt/local/csvn/data/repositories/www/db/revs/0/417:26066 [400,
#160004]
[Wed Sep 11 11:24:49.562363 2013] [dav:error] [pid 10826] [client
192.168.0.139:53897] Provider encountered an error while streaming a
REPORT response. [400, #0]
[Wed Sep 11 11:24:49.562447 2013] [dav:error] [pid 10826] [client
192.168.0.139:53897] Corrupt representation '417 26025 111 111
efae71eb2827965140f7f6208f62b720' [400, #160004]
[Wed Sep 11 11:24:49.562478 2013] [dav:error] [pid 10826] [client
192.168.0.139:53897] Corrupt representation '417 26025 111 111
efae71eb2827965140f7f6208f62b720' [400, #160004]
[Wed Sep 11 11:24:49.562504 2013] [dav:error] [pid 10826] [client
192.168.0.139:53897] Malformed representation header at
/opt/local/csvn/data/repositories/www/db/revs/0/417:26066 [400,
#160004]
[Wed Sep 11 11:29:18.880510 2013] [dav:error] [pid 5914] [client
192.168.0.139:53973] Corrupt node-revision '0-1.0.r6/1022' [400,
#160004]
[Wed Sep 11 11:29:18.880533 2013] [dav:error] [pid 5914] [client
192.168.0.139:53973] Corrupt node-revision '0-1.0.r6/1022' [400,
#160004]
[Wed Sep 11 11:29:18.880541 2013] [dav:error] [pid 5914] [client
192.168.0.139:53973] Found malformed header '.0.r6/1015' in revision
file [400, #160004]
[Wed Sep 11 11:29:30.637622 2013] [dav:error] [pid 5914] [client
192.168.0.139:53983] Corrupt node-revision '0-1.0.r6/1022' [400,
#160004]
[Wed Sep 11 11:29:30.637646 2013] [dav:error] [pid 5914] [client
192.168.0.139:53983] Corrupt node-revision '0-1.0.r6/1022' [400,
#160004]
[Wed Sep 11 11:29:30.637654 2013] [dav:error] [pid 5914] [client
192.168.0.139:53983] Found malformed header '.0.r6/1015' in revision
file [400, #160004]
[Wed Sep 11 11:29:41.634070 2013] [dav:error] [pid 5914] [client
192.168.0.139:53993] Could not fetch resource information. [500, #0]
[Wed Sep 11 11:29:41.634094 2013] [dav:error] [pid 5914] [client
192.168.0.139:53993] Error checking kind of path '/branches' in
repository [500, #160004]
[Wed Sep 11 11:29:41.634101 2013] [dav:error] [pid 5914] [client
192.168.0.139:53993] Corrupt node-revision '2-1.0.r4/250' [500,
#160004]
[Wed Sep 11 11:29:41.634106 2013] [dav:error] [pid 5914] [client
192.168.0.139:53993] Missing id field in node-rev [500, #160004]
[Wed Sep 11 11:32:27.826787 2013] [dav:error] [pid 5914] [client
192.168.0.139:54010] Corrupt node-revision '0-1.0.r6/1022' [400,
#160004]
[Wed Sep 11 11:32:27.826811 2013] [dav:error] [pid 5914] [client
192.168.0.139:54010] Corrupt node-revision '0-1.0.r6/1022' [400,
#160004]
[Wed Sep 11 11:32:27.826818 2013] [dav:error] [pid 5914] [client
192.168.0.139:54010] Found malformed header '.0.r6/1015' in revision
file [400, #160004]
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Lieven Govaerts <li...@gmail.com>.
On Wed, Sep 11, 2013 at 6:26 PM, Curt Sellmer <se...@gmail.com> wrote:
> On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer <se...@gmail.com> wrote:
>> On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer <se...@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 <be...@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
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Curt Sellmer <se...@gmail.com>.
On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer <se...@gmail.com> wrote:
> On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer <se...@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 <be...@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
Posted by Curt Sellmer <se...@gmail.com>.
On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer <se...@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 <be...@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
Posted by Curt Sellmer <se...@gmail.com>.
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 <be...@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
Posted by Ben Reser <be...@reser.org>.
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
Posted by Curt Sellmer <se...@gmail.com>.
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'
--------------------------
Here is the new --version info
$ svn --version --verbose
svn, version 1.8.3 (r1516576)
compiled Sep 10 2013, 22:18:41 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.
- using serf 1.3.1
- handles 'http' scheme
- handles 'https' scheme
System information:
* running on x86_64-apple-darwin12.4.0
- Mac OS X 10.8.4 Mountain Lion, build 12E55
* linked dependencies:
- APR 1.4.5 (compiled with 1.4.5)
- APR-Util 1.3.12 (compiled with 1.3.12)
- SQLite 3.8.0.2 (compiled with 3.8.0.2)
* loaded shared libraries:
- /Users/curt/Downloads/subversion-1.8.3/subversion/svn/.libs/svn
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_client/.libs/libsvn_client-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_wc/.libs/libsvn_wc-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra/.libs/libsvn_ra-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_diff/.libs/libsvn_diff-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_repos/.libs/libsvn_repos-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs/.libs/libsvn_fs-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs_util/.libs/libsvn_fs_util-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.0.dylib
(Intel 64-bit)
- /usr/lib/libsasl2.2.dylib (Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_serf/.libs/libsvn_ra_serf-1.0.dylib
(Intel 64-bit)
- /Users/curt/local/lib/libserf-1.3.0.0.dylib (Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_delta/.libs/libsvn_delta-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_subr/.libs/libsvn_subr-1.0.dylib
(Intel 64-bit)
- /usr/lib/libexpat.1.dylib (Intel 64-bit)
- /usr/lib/libz.1.dylib (Intel 64-bit)
- /usr/local/opt/sqlite/lib/libsqlite3.0.dylib (Intel 64-bit)
- /usr/local/lib/libmagic.1.dylib (Intel 64-bit)
- /usr/lib/libaprutil-1.0.dylib (Intel 64-bit)
- /usr/lib/libapr-1.0.dylib (Intel 64-bit)
- /usr/lib/libSystem.B.dylib (Intel 64-bit)
- /usr/lib/libiconv.2.dylib (Intel 64-bit)
- /usr/lib/libsqlite3.dylib (Intel 64-bit)
- /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 <se...@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 8:39 PM, Ben Reser <be...@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' scheme
> - handles 'https' scheme
>
> System information:
>
> * running on x86_64-apple-darwin12.4.0
> - Mac OS X 10.8.4 Mountain Lion, build 12E55
> * linked dependencies:
> - APR 1.4.5 (compiled with 1.4.5)
> - APR-Util 1.3.12 (compiled with 1.3.12)
> - SQLite 3.8.0.2 (compiled with 3.8.0)
> * loaded shared libraries:
> - /usr/local/bin/svn (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_client-1.0.dylib
> (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_wc-1.0.dylib (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_ra-1.0.dylib (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_diff-1.0.dylib
> (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_ra_local-1.0.dylib
> (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_repos-1.0.dylib
> (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_fs-1.0.dylib (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_fs_fs-1.0.dylib
> (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_fs_util-1.0.dylib
> (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_ra_svn-1.0.dylib
> (Intel 64-bit)
> - /usr/lib/libsasl2.2.dylib (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_ra_serf-1.0.dylib
> (Intel 64-bit)
> - /usr/local/lib/libserf-1.0.dylib (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_delta-1.0.dylib
> (Intel 64-bit)
> - /usr/local/Cellar/subversion/1.8.0/lib/libsvn_subr-1.0.dylib
> (Intel 64-bit)
> - /usr/lib/libexpat.1.dylib (Intel 64-bit)
> - /usr/lib/libz.1.dylib (Intel 64-bit)
> - /usr/local/opt/sqlite/lib/libsqlite3.0.dylib (Intel 64-bit)
> - /usr/lib/libaprutil-1.0.dylib (Intel 64-bit)
> - /usr/lib/libapr-1.0.dylib (Intel 64-bit)
> - /usr/lib/libSystem.B.dylib (Intel 64-bit)
> - /usr/lib/libiconv.2.dylib (Intel 64-bit)
> - /usr/lib/libsqlite3.dylib (Intel 64-bit)
> - /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)
>
>
> And here from the 1.8.3 client (also using serf 1.2.1)
>
> svn, version 1.8.3 (r1516576)
> compiled Sep 10 2013, 15:36:31 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.
> - using serf 1.2.1
> - handles 'http' scheme
> - handles 'https' scheme
>
> System information:
>
> * running on x86_64-apple-darwin12.4.0
> - Mac OS X 10.8.4 Mountain Lion, build 12E55
> * linked dependencies:
> - APR 1.4.5 (compiled with 1.4.5)
> - APR-Util 1.3.12 (compiled with 1.3.12)
> - SQLite 3.8.0.2 (compiled with 3.8.0.2)
> * loaded shared libraries:
> - /Users/curt/Downloads/subversion-1.8.3/subversion/svn/.libs/svn
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_client/.libs/libsvn_client-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_wc/.libs/libsvn_wc-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra/.libs/libsvn_ra-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_diff/.libs/libsvn_diff-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_repos/.libs/libsvn_repos-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs/.libs/libsvn_fs-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs_util/.libs/libsvn_fs_util-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.0.dylib
> (Intel 64-bit)
> - /usr/lib/libsasl2.2.dylib (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_serf/.libs/libsvn_ra_serf-1.0.dylib
> (Intel 64-bit)
> - /usr/local/lib/libserf-1.0.dylib (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_delta/.libs/libsvn_delta-1.0.dylib
> (Intel 64-bit)
> - /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_subr/.libs/libsvn_subr-1.0.dylib
> (Intel 64-bit)
> - /usr/lib/libexpat.1.dylib (Intel 64-bit)
> - /usr/lib/libz.1.dylib (Intel 64-bit)
> - /usr/local/opt/sqlite/lib/libsqlite3.0.dylib (Intel 64-bit)
> - /usr/local/lib/libmagic.1.dylib (Intel 64-bit)
> - /usr/lib/libaprutil-1.0.dylib (Intel 64-bit)
> - /usr/lib/libapr-1.0.dylib (Intel 64-bit)
> - /usr/lib/libSystem.B.dylib (Intel 64-bit)
> - /usr/lib/libiconv.2.dylib (Intel 64-bit)
> - /usr/lib/libsqlite3.dylib (Intel 64-bit)
> - /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 Tue, Sep 10, 2013 at 8:39 PM, Ben Reser <be...@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.
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Curt Sellmer <se...@gmail.com>.
On Tue, Sep 10, 2013 at 8:39 PM, Ben Reser <be...@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' scheme
- handles 'https' scheme
System information:
* running on x86_64-apple-darwin12.4.0
- Mac OS X 10.8.4 Mountain Lion, build 12E55
* linked dependencies:
- APR 1.4.5 (compiled with 1.4.5)
- APR-Util 1.3.12 (compiled with 1.3.12)
- SQLite 3.8.0.2 (compiled with 3.8.0)
* loaded shared libraries:
- /usr/local/bin/svn (Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_client-1.0.dylib
(Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_wc-1.0.dylib (Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_ra-1.0.dylib (Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_diff-1.0.dylib
(Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_ra_local-1.0.dylib
(Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_repos-1.0.dylib
(Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_fs-1.0.dylib (Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_fs_fs-1.0.dylib
(Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_fs_util-1.0.dylib
(Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_ra_svn-1.0.dylib
(Intel 64-bit)
- /usr/lib/libsasl2.2.dylib (Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_ra_serf-1.0.dylib
(Intel 64-bit)
- /usr/local/lib/libserf-1.0.dylib (Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_delta-1.0.dylib
(Intel 64-bit)
- /usr/local/Cellar/subversion/1.8.0/lib/libsvn_subr-1.0.dylib
(Intel 64-bit)
- /usr/lib/libexpat.1.dylib (Intel 64-bit)
- /usr/lib/libz.1.dylib (Intel 64-bit)
- /usr/local/opt/sqlite/lib/libsqlite3.0.dylib (Intel 64-bit)
- /usr/lib/libaprutil-1.0.dylib (Intel 64-bit)
- /usr/lib/libapr-1.0.dylib (Intel 64-bit)
- /usr/lib/libSystem.B.dylib (Intel 64-bit)
- /usr/lib/libiconv.2.dylib (Intel 64-bit)
- /usr/lib/libsqlite3.dylib (Intel 64-bit)
- /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)
And here from the 1.8.3 client (also using serf 1.2.1)
svn, version 1.8.3 (r1516576)
compiled Sep 10 2013, 15:36:31 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.
- using serf 1.2.1
- handles 'http' scheme
- handles 'https' scheme
System information:
* running on x86_64-apple-darwin12.4.0
- Mac OS X 10.8.4 Mountain Lion, build 12E55
* linked dependencies:
- APR 1.4.5 (compiled with 1.4.5)
- APR-Util 1.3.12 (compiled with 1.3.12)
- SQLite 3.8.0.2 (compiled with 3.8.0.2)
* loaded shared libraries:
- /Users/curt/Downloads/subversion-1.8.3/subversion/svn/.libs/svn
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_client/.libs/libsvn_client-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_wc/.libs/libsvn_wc-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra/.libs/libsvn_ra-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_diff/.libs/libsvn_diff-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_repos/.libs/libsvn_repos-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs/.libs/libsvn_fs-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_fs_util/.libs/libsvn_fs_util-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.0.dylib
(Intel 64-bit)
- /usr/lib/libsasl2.2.dylib (Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_ra_serf/.libs/libsvn_ra_serf-1.0.dylib
(Intel 64-bit)
- /usr/local/lib/libserf-1.0.dylib (Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_delta/.libs/libsvn_delta-1.0.dylib
(Intel 64-bit)
- /Users/curt/Downloads/subversion-1.8.3/subversion/libsvn_subr/.libs/libsvn_subr-1.0.dylib
(Intel 64-bit)
- /usr/lib/libexpat.1.dylib (Intel 64-bit)
- /usr/lib/libz.1.dylib (Intel 64-bit)
- /usr/local/opt/sqlite/lib/libsqlite3.0.dylib (Intel 64-bit)
- /usr/local/lib/libmagic.1.dylib (Intel 64-bit)
- /usr/lib/libaprutil-1.0.dylib (Intel 64-bit)
- /usr/lib/libapr-1.0.dylib (Intel 64-bit)
- /usr/lib/libSystem.B.dylib (Intel 64-bit)
- /usr/lib/libiconv.2.dylib (Intel 64-bit)
- /usr/lib/libsqlite3.dylib (Intel 64-bit)
- /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 Tue, Sep 10, 2013 at 8:39 PM, Ben Reser <be...@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.
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Ben Reser <be...@reser.org>.
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.
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Curt Sellmer <se...@gmail.com>.
On Tue, Sep 10, 2013 at 3:59 PM, Curt Sellmer <se...@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn <jc...@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 <se...@gmail.com> wrote:
>>> On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>>> On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer <se...@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
Re: Error during 'svn export' over http with serf 1.3.1
Posted by Curt Sellmer <se...@gmail.com>.
On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn <jc...@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 <se...@gmail.com> wrote:
>> On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer <se...@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