Re: Error during 'svn export' over http with serf 1.3.1
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
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 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. >
svn: E195016: merge error is dropping last character of path
So... any reason why the last character in paths are getting dropped in the "Missing ranges: " output? Ex: the "k" is missing from "trunk" in "Missing ranges: portal/trunk Missing ranges: /portal/trun:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 Or, maybe the problem is limited to the first entry? Ex: the 'g' is getting left off in the first "Missing ranges". portal/trunk/config Missing ranges: /portal/trunk/confi:4217,4378,4459 Missing ranges: /portal/trunk/config:4387,4435,4452 More importantly, if the first pathname is getting mangled, is it affecting how merges are resolved/calculated? Or is it just a presentation bug? This is 1.8.3 cygwin CLI client and in TortoiseSVN 1.8.1. == svn: E195016: Reintegrate can only be used if revisions 4109 through 4928 were previously merged from https://server/some/where/branches/foo to the reintegrate source, but this is not the case: portal/trunk Missing ranges: /portal/trun:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 portal/trunk/config Missing ranges: /portal/trunk/confi:4217,4378,4459 Missing ranges: /portal/trunk/config:4387,4435,4452 portal/trunk/doc Missing ranges: /portal/trunk/do:4378 portal/trunk/httpd-config Missing ranges: /portal/trunk/httpd-confi:4378 portal/trunk/private-certs Missing ranges: /portal/trunk/private-cert:4378 portal/trunk/schema Missing ranges: /portal/trunk/schem:4209,4217,4378 Missing ranges: /portal/trunk/schema:4209 portal/trunk/schema-newbase Missing ranges: /portal/trunk/schema-newbas:4217,4364,4378,4459 Missing ranges: /portal/trunk/schema-newbase:4241,4249-4250,4258-4261,4302,4354,4363-4364,4370,4377,4391,4420,4446-4450 portal/trunk/scripts Missing ranges: /portal/trunk/script:4147,4217,4378,4459 Missing ranges: /portal/trunk/scripts:4147,4236,4307,4371,4387,4390,4392,4459 portal/trunk/source Missing ranges: /portal/trunk/sourc:4125,4143,4145,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 Missing ranges: /portal/trunk/source:4114,4125,4135,4137,4143,4145,4150,4162-4163,4166,4168,4170,4186,4191-4194,4196-4199,4207-4209,4217,4219,4222,4225-4226,4228-4235,4237-4240,4243-4247,4252-4257,4265-4272,4274,4278-4279,4282,4285-4295,4300,4303-4306,4308-4328,4332-4335,4337-4343,4347-4348,4353,4355,4359,4364-4365,4367,4374-4376,4378,4383-4386,4388-4389,4394-4419,4421-4432,4434,4436-4437,4439,4441,-4445,4451,4455-4457,4462,4465-4467,4469 portal/trunk/source/includes/quotebuilder/changeorder_dealer_products_add.php Missing ranges: /portal/trunk/source/includes/quotebuilder/changeorder_dealer_products_add.ph:4125,4163,4217,4227,4378 portal/trunk/wsbin Missing ranges: /portal/trunk/wsbi:4277,4378 Missing ranges: /portal/trunk/wsbin:4273 Andrew Reedick CBeyond Cloud Development, SCM O: 678.486.8163
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer wrote: > On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer 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 wrote: >>> On 9/10/13 10:41 PM, Curt Sellmer wrote: I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn: E120104: ra_serf: An error occurred during decompression" error as often at the moment. Have seen it a few times. But I do intermittently get several different errors as show below. - Note that I am running the command over and over repeatedly many times. - I again performed 'svnadmin verify' with no errors reported. - I also ran these commands on the server box using the file:// scheme and never once saw an error. -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '13 1653716 109 109 a6a53d8aefe9d34461e08f7521119e5f' -- $ svn cat http://gemini2/svn/ezappliance/trunk/README svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/ezappliance/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/ezappliance/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' -- $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/bedrock/trunk/Rakefile' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/bedrock/trunk/Rakefile' svn: E160004: Additional errors: svn: E160004: Corrupt representation '29 13323 277 277 634ce706c8679810cb16ec44c9c6c532' >>> >>> Are you sure the server end is ok? Those errors are signs of a corrupted >>> repository. I'm starting to wonder if you're not having issues due to a >>> hardware issue on the server side. Failing memory could explain the >>> behavior >>> you're seeing. >>> > > > I installed client version 1.7.11 and I do occasionally get an error > when accessing a > repo with db format 6. > > $ svn log http://gemini2/svn/www/branches > svn: E175002: REPORT of '/svn/www/!svn/rvr/496/branches': Could not > read chunk size: connection was closed by server (http://gemini2) > > running this against the repo with db format 4 does not cause the > problem with 1.7.11. > I have seen the decompression problem using 1.8.3 against the format 4 repo. > > I have still never seen a problem when running locally using the > file:// scheme and I have repeated the command many many times. This > indicates that the repo is ok and the problem has to do with serving > the data over http://. Using: 1.8.3 client (serf 1.3.1) Connecting to: repo with db format 6 (I dumped and loaded the format 4 repo to a new format 6 again) Seems the path is significant in what errors I receive. $ svn log http://gemini2/svn/www Ran this command 50 times with no errors. $ svn log http://gemini2/svn/www/trunk Ran this 50 times and got the following error 5 times. Interesting to note that commit 496 was made on a branch. svn: E175002: Unable to connect to a repository at URL 'http://gemini2/svn/www/trunk' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/svn/www/trunk' svn: E160004: Additional errors: svn: E160004: Corrupt representation '496 2752 110 0 8733d74a90f550a19dddad89a54718fa' $ svn log http://gemini2/svn/www/branches Ran this 15 times and got the following error 12 times. svn: E120104: ra_serf: An error occurred during decompression
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer 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 wrote: >> On 9/10/13 10:41 PM, Curt Sellmer wrote: >>> I now have svn 1.8.3 with serf 1.3.1. I am not seeing the "svn: >>> E120104: ra_serf: An error occurred during decompression" error as >>> often at the moment. Have seen it a few times. >>> >>> But I do intermittently get several different errors as show below. >>>- Note that I am running the command over and over repeatedly many >>> times. >>>- I again performed 'svnadmin verify' with no errors reported. >>>- I also ran these commands on the server box using the file:// >>> scheme and never once saw an error. >>> >>> -- >>> $ svn cat http://gemini2/svn/ezappliance/trunk/README >>> svn: E175002: Unable to connect to a repository at URL >>> 'http://gemini2/svn/ezappliance/trunk' >>> svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on >>> '/svn/ezappliance/trunk' >>> >>> svn: E160004: Additional errors: >>> svn: E160004: Corrupt representation '13 1653716 109 109 >>> a6a53d8aefe9d34461e08f7521119e5f' >>> >>> -- >>> $ svn cat http://gemini2/svn/ezappliance/trunk/README >>> svn: E175002: Unable to connect to a repository at URL >>> 'http://gemini2/svn/ezappliance/trunk' >>> svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on >>> '/svn/ezappliance/trunk' >>> >>> svn: E160004: Additional errors: >>> svn: E160004: Corrupt node-revision '0-1.0.r13/1653516' >>> >>> -- >>> $ svn log http://gemini2/svn/bedrock/trunk/Rakefile@3 >>> svn: E175002: Unable to connect to a repository at URL >>> 'http://gemini2/svn/bedrock/trunk/Rakefile' >>> svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on >>> '/svn/bedrock/trunk/Rakefile' >>> >>> svn: E160004: Additional errors: >>> svn: E160004: Corrupt representation '29 13323 277 277 >>> 634ce706c8679810cb16ec44c9c6c532' >> >> Are you sure the server end is ok? Those errors are signs of a corrupted >> repository. I'm starting to wonder if you're not having issues due to a >> hardware issue on the server side. Failing memory could explain the behavior >> you're seeing. >> I installed client version 1.7.11 and I do occasionally get an error when accessing a repo with db format 6. $ svn log http://gemini2/svn/www/branches svn: E175002: REPORT of '/svn/www/!svn/rvr/496/branches': Could not read chunk size: connection was closed by server (http://gemini2) running this against the repo with db format 4 does not cause the problem with 1.7.11. I have seen the decompression problem using 1.8.3 against the format 4 repo. I have still never seen a problem when running locally using the file:// scheme and I have repeated the command many many times. This indicates that the repo is ok and the problem has to do with serving the data over http://.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 6:26 PM, Curt Sellmer wrote: > On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer wrote: >> On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer 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 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
On Wed, Sep 11, 2013 at 12:17 PM, Lieven Govaerts wrote: > On Wed, Sep 11, 2013 at 6:26 PM, Curt Sellmer wrote: >> On Wed, Sep 11, 2013 at 11:02 AM, Curt Sellmer wrote: >>> On Wed, Sep 11, 2013 at 8:11 AM, Curt Sellmer 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 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 t
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote: > On 9/11/13 12:24 PM, Curt Sellmer wrote: >> Here is a tail of the error.log. This is from when I was running the >> tests earlier. >> I was hoping to pinpoint which set of log messages corresponded to >> each error, but of >> course I cannot get it to fail at all right now. I'll keep trying >> throughout the day. > > Based on the error messages you've been posting I'd suggest that you run > svnadmin verify on your repository. > I just ran svnadmin verify on the repo again and still it does not report any errors.
Re: Error during 'svn export' over http with serf 1.3.1
On 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
On Wed, Sep 11, 2013 at 3:04 PM, Curt Sellmer wrote: > On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote: >> On 9/11/13 12:24 PM, Curt Sellmer wrote: >>> Here is a tail of the error.log. This is from when I was running the >>> tests earlier. >>> I was hoping to pinpoint which set of log messages corresponded to >>> each error, but of >>> course I cannot get it to fail at all right now. I'll keep trying >>> throughout the day. >> >> Based on the error messages you've been posting I'd suggest that you run >> svnadmin verify on your repository. >> > > I just ran svnadmin verify on the repo again and still it does not > report any errors. Here is a new one. Running 1.8.3 client against 1.8.1 server. repo is format 4. svnadmin verity reports no problems. $ svn ls http://gemini2/svn/roclock/trunk svn: E24: Could not convert '###error###' into a number error.log on server logs this: [Wed Sep 11 18:40:14.393500 2013] [:error] [pid 14479] (160004)APR does not understand this error code: [client 192.168.0.139:55525] Can't fetch proplist of '/trunk': Corrupt representation '137 5727 30 0 bccc4074133de2a54dfaee6dfacbfede' Now when I run my 1.7.11 client against the same repo it works fine. This is reproducible every time. I created a new repo (format 6) dumped/loaded. The 1.8.3 client works fine against the new repo.
Re: Error during 'svn export' over http with serf 1.3.1
Curt Sellmer writes: > On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser 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
On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin wrote: > Curt Sellmer writes: > >> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote: >>> On 9/11/13 12:24 PM, Curt Sellmer wrote: Here is a tail of the error.log. This is from when I was running the tests earlier. I was hoping to pinpoint which set of log messages corresponded to each error, but of course I cannot get it to fail at all right now. I'll keep trying throughout the day. >>> >>> Based on the error messages you've been posting I'd suggest that you run >>> svnadmin verify on your repository. >>> >> >> I just ran svnadmin verify on the repo again and still it does not >> report any errors. > > You said you dumped and loaded your repository. You also have > corruption shown by apache that is not shown by svnadmin. When you > dump/load are you also putting the new repository in the same place as > the old repository? If so, are you restarting apache? It's perfectly > acceptable to replace a repository but you must restart apache if the > repository is altered but the UUID is not changed. > > -- > Philip Martin | Subversion Committer > WANdisco // *Non-Stop Data* In this case I created a new repo using a different name. I left the old one intact. Then just referenced the new repo's url. In the last few days, thought I have moved the old repo to A.orig then moved the new repo to A. I did not know of the requirement to restart apache. Will do that going forward. Thanks.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 7:04 PM, Curt Sellmer wrote: > On Wed, Sep 11, 2013 at 6:51 PM, Philip Martin > wrote: >> Curt Sellmer writes: >> >>> On Wed, Sep 11, 2013 at 2:46 PM, Ben Reser wrote: On 9/11/13 12:24 PM, Curt Sellmer wrote: > Here is a tail of the error.log. This is from when I was running the > tests earlier. > I was hoping to pinpoint which set of log messages corresponded to > each error, but of > course I cannot get it to fail at all right now. I'll keep trying > throughout the day. Based on the error messages you've been posting I'd suggest that you run svnadmin verify on your repository. >>> >>> I just ran svnadmin verify on the repo again and still it does not >>> report any errors. >> >> You said you dumped and loaded your repository. You also have >> corruption shown by apache that is not shown by svnadmin. When you >> dump/load are you also putting the new repository in the same place as >> the old repository? If so, are you restarting apache? It's perfectly >> acceptable to replace a repository but you must restart apache if the >> repository is altered but the UUID is not changed. >> >> -- >> Philip Martin | Subversion Committer >> WANdisco // *Non-Stop Data* > > In this case I created a new repo using a different name. I left the > old one intact. Then just referenced the new repo's url. > > In the last few days, thought I have moved the old repo to A.orig then > moved the new repo to A. I did not know of the requirement to restart > apache. Will do that going forward. Thanks. I just bounced the apache server and it did indeed clear up the problem. I can now access the repo with both clients. Thank you. I apologize that I didn't realize that the web server had to be bounced. Not sure that was in the docs anywhere? This may well be the cause of the previous problems as I had a script that would create a new repo, dump | load to it, then rename the new repo with the original repo's name. I'll keep testing with the new found knowledge.
Re: Error during 'svn export' over http with serf 1.3.1
On Wed, Sep 11, 2013 at 7:19 PM, Curt Sellmer 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: Breaking up a monolothic repository
Les, disk space isn't the issue for the empty revs. It's any operations that try to scan or assemble information from the revisions. 5000 empty "objects" is still a logistical burden, especially if assembling any kind of change history for the new repository. And since the new repositories are effectively a rebase of a subset of the code, you don't normally *gain* anything from having empty revisions for code that is in the other new repositories. You can't meaninglfully merge content between the new smaller repositories and the old repo, barring some seriously weird cases, so it's safer to treat them as completely distinct and not bother to preserve all the empty revisions. The "revision numbers are stored in support tickets" is the only reason I can think of to keep them. On Tue, Sep 10, 2013 at 11:35 AM, Les Mikesell wrote: > On Tue, Sep 10, 2013 at 6:22 AM, Nico Kadel-Garcia > wrote: > >> > > Even if the history is considered sacrosanct (and this is often a > > theological policy, not an engineering one!), an opportunity to reduce > the > > size of each reaporitory by discarding deadwood at switchover time > should be > > taken seriously. > > Those empty revs take what, a couple of dollars worth of disk space > (OK, x3 or 4 for backups...), vs. how much human time will it take to > make everyone involved understand that you use one procedure for > revisions before a certain date, and a different one after, and to get > diffs between them you have to either check out both copies and use > local tools or map the rev number from your old reference to the new > numbering scheme? And then there are likely to be pegged externals > to pull in components that you'll have to fix even if they stay within > the same project repo and use relative notation. I'd call not > unnecessarily changing the history you use a version control system to > preserve to be 'philosophically correct' as opposed to a theological > requirement. If your engineering choices were always right the first > time, you probably wouldn't have all these revisions in the first > place. > > -- >Les Mikesell > lesmikes...@gmail.com >
Re: libsvn_ra_serf/util.c: undefined reference to serf_bucket_request_set_CL [1.8.1][1.8.3][WORKAROUND]
On 9/8/13 4:12 PM, Nico Kadel-Garcia wrote: > This is why you either update a system version that is high enough, or you use > the "get-deps.sh" to pull down versions locally and compile them statically. > I've been publishing up-to-date get-deps.sh, slightly more consistent in > layout > and up-to-date, at > https://github.com/nkadel/subversion-1.8.x-srpm/blob/master/get-deps.sh. He does have a legitimate complaint, the problem is that Debian's serf isn't new enough and our configure should be complaining. > Can we possibly get that updated get-deps.sh into the main code line? Make a patch and submit it along with a commit message explaining the reasoning for your changes. Some comments from looking at your script now: 1) The nested command substitutions in setting the SQLITE need to be broken up to be compatible with POSIX shells. You should avoid using $() since there are some shells that don't implement this (despite the fact that it's in the POSIX standard). 2) What's the motivation for reordering stuff all over the place. It just seem gratutitous and it doesn't really matter what order get-deps.sh downloads things. What it does achieve is to make your differences very difficult to actually see. 3) As far as I know the newest version of APR iconv is 1.2.1, your script is defaulting to 1.2.6 4) Is there some particular reason to want SQLITE 3.7.17 versus 3.7.15.1? We don't typically bump version numbers once a 1.x.0 has been released unless there's a specific reason to. 5) There's no reason to download gtest since nothing actually uses it yet. 6) What's the point of all the || return 1? The existing test when using user provided deps list is to show the usage if someone tries to use a deps name we don't have implemented. I mean I can see the value in checking that the commands actually suceeded but when you just run the script with no command it doesn't do anything with that return and when there is an error it just prints the usage, which is hugely confusing.
Re: libsvn_ra_serf/util.c: undefined reference to serf_bucket_request_set_CL [1.8.1][1.8.3][WORKAROUND]
On 9/2/13 9:20 AM, Klaus Thorn wrote:
> I am mailing this just to make the workaround known to other users.
>
> When compiling subversion 1.8.1 or 1.8.3 from apache's source package,
> "configure --with-serf=/usr/local/serf" is not enough to use a specific serf
> version.
> Not if another version was installed as debian packages.
>
> Workaround:
> Uninstall the debian packages, then do "make install" again.
>
> Symptom:
> "make install" fails with:
>
> cd subversion/libsvn_ra_serf ;
> [...] libtool: install: warning: relinking `libsvn_ra_serf-1.la'
> [...] .libs/util.o: In function `setup_serf_req':
> [...]/subversion-1.8.3/subversion/libsvn_ra_serf/util.c:760: undefined
> reference to `serf_bucket_request_set_CL'
> [...]/subversion-1.8.3/subversion/libsvn_ra_serf/util.c:758: undefined
> reference to `serf_bucket_request_set_CL'
> collect2: ld returned 1 exit status
> libtool: install: error: relink `libsvn_ra_serf-1.la' with the above command
> before installing it
> make: *** [install-serf-lib] Fehler 1
>
> ("Fehler" is German for "Error")
>
>
> Tested with Ubuntu 12.04 x64 and the distribution's standart libserf1 and
> libserf-dev packages.
Can you post the config.log file from a build with this behavior?
That should be helpful in figuring out why our configure isn't dealing with
this properly.
svn.exe crashed when output of 'log' command interrupted
Reproduced on:
svn, version 1.8.4-dev (under development)
compiled Aug 23 2013, 17:30:38 on x86-microsoft-windows
svn, version 1.8.3 (r1516576)
compiled Aug 27 2013, 22:13:03 on x86-microsoft-windows
svn, version 1.8.0 (r1490375)
compiled Jun 18 2013, 13:38:49 on x86/x86_64-microsoft-windows6.1.7601
Windows + cygwin.
Steps:
svn.exe log | less
show first N log entries. Then press 'q' for exit. svn.exe application
crashed.
Same crash for
svn.exe log | more
Crashed in apr\memory\unix\apr_pools.c line 681:
active = pool->active;
pool parameter not initialized:
pool = 0x3b0f363b552b0a7f {parent=??? child=??? sibling=??? ...}
Call stack:
> libapr_tsvn.dll!apr_palloc(apr_pool_t * pool, unsigned __int64 in_size)
Line 681 C
libsvn_tsvn.dll!make_error_internal(int apr_err, svn_error_t * child)
Line 118 C
libsvn_tsvn.dll!svn_error__trace(const char * file, long line,
svn_error_t * err) Line 245 C
libsvn_tsvn.dll!expat_response_handler(serf_request_t * request,
serf_bucket_t * response, void * baton, apr_pool_t * scratch_pool) Line 2634
C
libsvn_tsvn.dll!handle_response(serf_request_t * request, serf_bucket_t *
response, svn_ra_serf__handler_t * handler, int * serf_status, apr_pool_t *
scratch_pool) Line 2122 C
libsvn_tsvn.dll!handle_response_cb(serf_request_t * request,
serf_bucket_t * response, void * baton, apr_pool_t * scratch_pool) Line 2155
C
libsvn_tsvn.dll!handle_response(serf_request_t * request, apr_pool_t *
pool) Line 941 C
libsvn_tsvn.dll!read_from_connection(serf_connection_t * conn) Line 1127 C
libsvn_tsvn.dll!serf__process_connection(serf_connection_t * conn, short
events) Line 1248 C
libsvn_tsvn.dll!serf_event_trigger(serf_context_t * s, void * serf_baton,
const apr_pollfd_t * desc) Line 227 C
libsvn_tsvn.dll!serf_context_run(serf_context_t * ctx, int duration,
apr_pool_t * pool) Line 294 C
libsvn_tsvn.dll!svn_ra_serf__context_run_wait(int * done,
svn_ra_serf__session_t * sess, apr_pool_t * scratch_pool) Line 819 C
libsvn_tsvn.dll!svn_ra_serf__context_run_one(svn_ra_serf__handler_t *
handler, apr_pool_t * scratch_pool) Line 889 C
libsvn_tsvn.dll!svn_ra_serf__get_log(svn_ra_session_t * ra_session, const
apr_array_header_t * paths, long start, long end, int limit, int
discover_changed_paths, int strict_node_history, int
include_merged_revisions, const apr_array_header_t * revprops, svn_error_t
* (void *, svn_log_entry_t *, apr_pool_t *) * receiver, void *
receiver_baton, apr_pool_t * pool) Line 595 C
libsvn_tsvn.dll!svn_ra_get_log2(svn_ra_session_t * session, const
apr_array_header_t * paths, long start, long end, int limit, int
discover_changed_paths, int strict_node_history, int
include_merged_revisions, const apr_array_header_t * revprops, svn_error_t
* (void *, svn_log_entry_t *, apr_pool_t *) * receiver, void *
receiver_baton, apr_pool_t * pool) Line 910 C
libsvn_tsvn.dll!run_ra_get_log(apr_array_header_t * revision_ranges,
apr_array_header_t * paths, apr_array_header_t * log_segments,
svn_client__pathrev_t * actual_loc, svn_ra_session_t * ra_session, const
apr_array_header_t * targets, int limit, int discover_changed_paths, int
strict_node_history, int include_merged_revisions, const apr_array_header_t
* revprops, svn_error_t * (void *, svn_log_entry_t *, apr_pool_t *) *
real_receiver, void * real_receiver_baton, svn_client_ctx_t * ctx,
apr_pool_t * scratch_pool) Line 782 C
libsvn_tsvn.dll!svn_client_log5(const apr_array_header_t * targets, const
svn_opt_revision_t * peg_revision, const apr_array_header_t *
opt_rev_ranges, int limit, int discover_changed_paths, int
strict_node_history, int include_merged_revisions, const apr_array_header_t
* revprops, svn_error_t * (void *, svn_log_entry_t *, apr_pool_t *) *
real_receiver, void * real_receiver_baton, svn_client_ctx_t * ctx,
apr_pool_t * pool) Line 894 C
svn.exe!svn_cl__log(apr_getopt_t * os, void * baton, apr_pool_t * pool)
Line 868 C
svn.exe!sub_main(int argc, const char * * argv, apr_pool_t * pool) Line
2878 C
svn.exe!main(int argc, const char * * argv) Line 2969 C
svn.exe!__tmainCRTStartup() Line 536 C
svn.exe!mainCRTStartup() Line 377 C
I also has minidump, but it is 60MB. I can send it by request.
