Re: I found a bug?about resolve conflict~
Guten Tag ºÚÉÁÖ, am Dienstag, 10. September 2013 um 01:07 schrieben Sie: (5)invoke maked resolved menu,checked Resolve conflicts in local file with my changes option, Test.java file content change bottom: [...] (6)My question is, why don't you into the following this? Look at 5, you said you want to resolve the conflict with the contents of your local file from 4 and that's what you got. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Breaking up a monolothic repository
Guten Tag Trent W. Buck, am Dienstag, 10. September 2013 um 02:49 schrieben Sie: ...hm, still 1.6. Is it worth me backporting a newer svn? I would give it a try, get yourself a current build of 1.8, dump your old repo and load it into a newly created from your 1.8 version and see how much space is saved. Your version information about the repo looks current enough to already use representation sharing, but depending on how the upgrades were made, svnadmin upgrade vs. full dump/load cycle, there maybe old duplicate data in the repo created before svnadmin upgrade. Besides that, 1.8 made improvements to reduce disk space, too. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Breaking up a monolothic repository
On 9/9/2013 8:49 PM, Trent W. Buck wrote: I'm partway through provisioning the replacement Debian 7 server, which will have subversion 1.6.17dfsg-4+deb7u3 apache22.2.22-13 ...hm, still 1.6. Is it worth me backporting a newer svn? Yes, it's worth installing 1.8.3. http://www.wandisco.com/subversion/download#debian7
Re: Breaking up a monolothic repository
Have you checked if the users have/need anything (emails, ticket system, etc.) that refer to specific revisions or the history of changes made there? It seems kind of drastic to throw that away because you think the numbers aren't pretty enough. But keeping thousands of empty commits in a project they're not relevant to is confusing and wasteful. The repository and repository URL's for the old project should be preserved, if possible, locked down and read-only, precisely for this kind of change history. But since the repository is being completely refactored *anyway*, it's a great opportunity to discard debris. 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.
Re: Username in Repository URL with Serf/ra_serf
Simon Wilson sepwil...@gmail.com writes: Subversion 1.8 throws up errors when I specify HTTP/HTTPS URLs that contain usernames to svn, i.e. svn --username user ls https://server.com/repos/project/ works fine but svn ls https://u...@server.com/repos/project/ results in errors. The same URL worked fine with Neon in 1.7 and older. I can reproduce this. I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4423 -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Is it possible to see a diff of a replaced file?
I'm referring to files with an 'R' status in 'svn log'. I want to see the changes between the new file, and the file that it replaced. I can use 'svn cat' to get the old file and then compare it to the new one, but I am hoping there is a way to have SVN run the diff for me in one step like it can for comparing two revisions of the same file (actually I use TortoiseSVN most of the time, but I'd be willing to drop to the command line for this task if needed). We have a directory that collects files from various projects in the repository for building release loadsets for an embedded target, and I've been using 'svn copy' to replace those files in order to see the pedigree of the file more easily, but since I did it this way, I didn't notice when I removed an update somebody made directly to a file in that location instead of making it in the project folder it belonged in.
Re: Breaking up a monolothic repository
On Tue, Sep 10, 2013 at 6:22 AM, Nico Kadel-Garcia nka...@gmail.com 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: 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 sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn jcor...@gmail.com wrote: On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer sellmer...@gmail.com wrote: On Sun, Aug 25, 2013 at 1:41 AM, Lieven Govaerts [hidden email] wrote: On Sun, Aug 25, 2013 at 1:36 AM, Johan Corveleyn [hidden email] wrote: ... FYI: another user has reported seeing the same error message (during a reintegrate merge ... not sure if it's the same issue, but the error is the same at least): http://svn.haxx.se/users/archive-2013-09/0070.shtml I came across this error message today as well. I recently upgraded my svn server to 1.8.1. I have been dumping my repos and loading them into new repos. On one particular repo, I get this error when doing the following command: svn log -l 4 http://server/repo/branches I get the error about 50% of the time. Interestingly when I run the same command against http://server/repo/trunk I never get the error. I tried disabling compression with --config-option servers:global:http-compression=off and when I do this about 50% of the time I get only the first two log entries. But no error is reported. So far I've only noticed the problem on one repo. I even did the dump/load a second time an the results are the same. What's your client version? Can you show the output of svn --version of the client? Here is version output from my dev box svn --version svn, version 1.8.0 (r1490375) compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme I am also seeing the problem when I run the command on the server box itself and using the 'http' scheme. Here is svn --version for that: svn, version 1.8.1 (r1503906) compiled Jul 24 2013, 11:57:22 on i686-pc-linux-gnu Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme -- Problem does not occur when using the 'file' scheme which makes sense. First thing to try is to test this with the latest client release, 1.8.3 (this uses serf 1.3.1 internally). A lot of connection-related bugs have been fixed already [1]. I have seen each of the following results when running the same command: svn: E120104: ra_serf: An error occurred during decompression svn: E160004: Corrupt representation '489 681 46 46 a2a7fa5ef17fb3ca svn: E070014: Can't read file '/opt/local/csvn/data/repositories/www/db/revs/0/489': End of file found And sometimes the command works successfully. Running svnadmin verify on the repo shows no problems. Hmm, that seems something different than what I'm seeing. In my case, I just got the decompression error, but no reference to a corrupt representation or a corrupt rev file. Are you sure that you can't reproduce this when executing the exact same command with file:// (which should read the same rev file)? And the error doesn't reproduce always, but only some of the time? I can reproduce this with several repos created by the new version 1.8.1 on the server. But other new repos do not cause it to happen. So far all of the existing repos do not cause the problem to occur. Format number from repo/db/format is 4 for existing and 6 for new repos. Hope this helps. Strange. As I said, first try with a 1.8.3 client, and see if it reproduces. Then, perhaps you can also update your server to 1.8.3, just to be sure that you're not chasing something that has already been fixed
Re: Breaking up a monolothic repository
On 9/10/2013 7:22 AM, Nico Kadel-Garcia wrote: But keeping thousands of empty commits in a project they're not relevant to is confusing and wasteful. The repository and repository URL's for the old project should be preserved, if possible, locked down and read-only, precisely for this kind of change history. But since the repository is being completely refactored *anyway*, it's a great opportunity to discard debris. When we moved from a monolithic repository to per-client repositories a few years ago, we went ahead and: - Rebased the paths up one or two levels (old system was something like monolithicrepo/[a-z]/[client directories]/[job directory]) so that the urls were now clientrepo/[job directory]. That was a tricky thing to do and we had to 'sed' the output of the dump filter before importing it back. It broke a few things, such as svn:externals which were not relative-pathed, but was worth it in the long run so that our URLs got shorter. - Made sure that the new repos all had unique UUIDs. - Renumbered all of the resulting revisions as we loaded things back in. But we didn't have to deal with any bug tracking systems that referred to a specific revision. And having lower revision numbers was preferred, along with dropping revisions that referred to other projects. 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 repository by discarding deadwood at switchover time should be taken seriously. Less of an issue now that svn 1.8 has revprop packing (plus the rev packing from 1.6). That deadwood takes up a lot less space in terms of the number of files in the file system. And the fact that svnadmin hotcopy is now incremental in 1.8 also makes it less of an issue. Having a few thousand (tens of thousands) revisions in a repository is no longer a big bottleneck during the hotcopy process like it was before. Our backup system is also a lot happier with fewer files to backup.
Re: Error during 'svn export' over http with serf 1.3.1
On Tue, Sep 10, 2013 at 3:59 PM, Curt Sellmer sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn jcor...@gmail.com wrote: [ Please use reply all to keep the list in the loop -- I'm sending this to users@ rather than dev@, because other users might also be interested and/or can chime in if someone has similar issues. Also, this list prefers bottom-posting or inline replying, so I've rearranged to put your reply at the bottom. More below. ] On Tue, Sep 10, 2013 at 4:47 PM, Curt Sellmer sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn jcor...@gmail.com wrote: On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer sellmer...@gmail.com wrote: On Sun, Aug 25, 2013 at 1:41 AM, Lieven Govaerts [hidden email] wrote: On Sun, Aug 25, 2013 at 1:36 AM, Johan Corveleyn [hidden email] wrote: ... FYI: another user has reported seeing the same error message (during a reintegrate merge ... not sure if it's the same issue, but the error is the same at least): http://svn.haxx.se/users/archive-2013-09/0070.shtml I came across this error message today as well. I recently upgraded my svn server to 1.8.1. I have been dumping my repos and loading them into new repos. On one particular repo, I get this error when doing the following command: svn log -l 4 http://server/repo/branches I get the error about 50% of the time. Interestingly when I run the same command against http://server/repo/trunk I never get the error. I tried disabling compression with --config-option servers:global:http-compression=off and when I do this about 50% of the time I get only the first two log entries. But no error is reported. So far I've only noticed the problem on one repo. I even did the dump/load a second time an the results are the same. What's your client version? Can you show the output of svn --version of the client? Here is version output from my dev box svn --version svn, version 1.8.0 (r1490375) compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme I am also seeing the problem when I run the command on the server box itself and using the 'http' scheme. Here is svn --version for that: svn, version 1.8.1 (r1503906) compiled Jul 24 2013, 11:57:22 on i686-pc-linux-gnu Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme -- Problem does not occur when using the 'file' scheme which makes sense. First thing to try is to test this with the latest client release, 1.8.3 (this uses serf 1.3.1 internally). A lot of connection-related bugs have been fixed already [1]. I have seen each of the following results when running the same command: svn: E120104: ra_serf: An error occurred during decompression svn: E160004: Corrupt representation '489 681 46 46 a2a7fa5ef17fb3ca svn: E070014: Can't read file '/opt/local/csvn/data/repositories/www/db/revs/0/489': End of file found And sometimes the command works successfully. Running svnadmin verify on the repo shows no problems. Hmm, that seems something different than what I'm seeing. In my case, I just got the decompression error, but no reference to a corrupt representation or a corrupt rev file. Are you sure that you can't reproduce this when executing the exact same command with file:// (which should read the same rev file)? And the error doesn't reproduce always, but only some of the time? I can reproduce this with several repos created by the new version 1.8.1 on the server. But other new repos do not cause it to happen. So far all of the existing repos do not cause the problem to occur. Format number from repo/db/format is 4 for existing and 6 for new repos. Hope this helps. Strange. As I said, first try with a 1.8.3
Re: Is it possible to see a diff of a replaced file?
On Tue, Sep 10, 2013 at 09:59:27AM -0500, Benjamin Fritz wrote: I'm referring to files with an 'R' status in 'svn log'. I want to see the changes between the new file, and the file that it replaced. 'svn diff' does that by default. You have to use the --notice-ancestry option to force svn not to show a diff between post-replaced and pre-replaced. So I wonder why you aren't seeing the expected behaviour. Maybe your Subversion client (Tortoise) sets the notice-ancestry flag by default? $ svn cat alpha alpha $ svn rm alpha D alpha $ echo foo alpha $ svn add alpha A alpha $ svn st alpha R alpha $ svn diff alpha Index: alpha === --- alpha (revision 2) +++ alpha (working copy) @@ -1 +1 @@ -alpha +foo $ svn diff --notice-ancestry alpha Index: alpha === --- alpha (revision 0) +++ alpha (working copy) @@ -1 +0,0 @@ -alpha Index: alpha === --- alpha (revision 0) +++ alpha (working copy) @@ -0,0 +1 @@ +foo $ svn commit -mm Replacing alpha Transmitting file data . Committed revision 3. $ svn log -v -r3 r3 | stsp | 2013-09-10 17:08:14 +0200 (Tue, 10 Sep 2013) | 1 line Changed paths: R /trunk/alpha m $ svn diff -c3 ^/trunk Index: alpha === --- alpha (revision 2) +++ alpha (revision 3) @@ -1 +1 @@ -alpha +foo $ svn diff -c3 --notice-ancestry ^/trunk Index: alpha === --- alpha (revision 2) +++ alpha (revision 3) @@ -1 +0,0 @@ -alpha Index: alpha === --- alpha (revision 0) +++ alpha (revision 3) @@ -0,0 +1 @@ +foo
RE: Breaking up a monolothic repository
-Original Message- From: t...@elba.apache.org [mailto:t...@elba.apache.org] On Behalf Of Trent W. Buck Sent: Monday, September 09, 2013 11:38 PM To: users@subversion.apache.org Subject: Re: Breaking up a monolothic repository Les Mikesell lesmikes...@gmail.com writes: On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck trentb...@gmail.com wrote: Ryan Schmidt subversion-20...@ryandesign.com writes: As someone used to Subversion's usually sequential revision numbers, that bugs me aesthetically, but it works fine. I think that's the crux of it. Have you checked if the users have/need anything (emails, ticket system, etc.) that refer to specific revisions or the history of changes made there? It seems kind of drastic to throw that away because you think the numbers aren't pretty enough. That is an extremely valid point. I'll check. Also part of the reason to split up the repos is to make access control easier, and it looks bad if Alice (who should have access to project 1 but not project 2) can see Bob's old commit metadata to project 2, even if she can't see the commit bodies after the split. How does this work now in the combined repository? Right now, they don't have it with the combined repo. Anyone in the svn group can read everything. (This is one of the reasons they want to break up the single repo into per-project repos.) You should knock the reason off the list. You can set up path based authorization fairly easily. (especially compared to braking it up into multiple repos.) BOb
Re: Breaking up a monolothic repository
On Tue, Sep 10, 2013 at 4:36 PM, Bob Archer bob.arc...@amsi.com wrote: Also part of the reason to split up the repos is to make access control easier, and it looks bad if Alice (who should have access to project 1 but not project 2) can see Bob's old commit metadata to project 2, even if she can't see the commit bodies after the split. How does this work now in the combined repository? Right now, they don't have it with the combined repo. Anyone in the svn group can read everything. (This is one of the reasons they want to break up the single repo into per-project repos.) You should knock the reason off the list. You can set up path based authorization fairly easily. (especially compared to braking it up into multiple repos.) Unless you already have a central authentication source you'll have a certain tradeoff in complexity between maintaining password control for multiple repos vs. path-based control in a single one and if there are external references where different groups use each others' libraries it can be a little messy either way. -- Les Mikesell lesmikes...@gmail.com
Re: Error during 'svn export' over http with serf 1.3.1
On Tue, Sep 10, 2013 at 1:42 PM, Johan Corveleyn jcor...@gmail.com wrote: [ Please use reply all to keep the list in the loop -- I'm sending this to users@ rather than dev@, because other users might also be interested and/or can chime in if someone has similar issues. Also, this list prefers bottom-posting or inline replying, so I've rearranged to put your reply at the bottom. More below. ] On Tue, Sep 10, 2013 at 4:47 PM, Curt Sellmer sellmer...@gmail.com wrote: On Tue, Sep 10, 2013 at 2:28 AM, Johan Corveleyn jcor...@gmail.com wrote: On Tue, Sep 10, 2013 at 5:36 AM, Curt Sellmer sellmer...@gmail.com wrote: On Sun, Aug 25, 2013 at 1:41 AM, Lieven Govaerts [hidden email] wrote: On Sun, Aug 25, 2013 at 1:36 AM, Johan Corveleyn [hidden email] wrote: ... FYI: another user has reported seeing the same error message (during a reintegrate merge ... not sure if it's the same issue, but the error is the same at least): http://svn.haxx.se/users/archive-2013-09/0070.shtml I came across this error message today as well. I recently upgraded my svn server to 1.8.1. I have been dumping my repos and loading them into new repos. On one particular repo, I get this error when doing the following command: svn log -l 4 http://server/repo/branches I get the error about 50% of the time. Interestingly when I run the same command against http://server/repo/trunk I never get the error. I tried disabling compression with --config-option servers:global:http-compression=off and when I do this about 50% of the time I get only the first two log entries. But no error is reported. So far I've only noticed the problem on one repo. I even did the dump/load a second time an the results are the same. What's your client version? Can you show the output of svn --version of the client? Here is version output from my dev box svn --version svn, version 1.8.0 (r1490375) compiled Aug 27 2013, 18:39:10 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme I am also seeing the problem when I run the command on the server box itself and using the 'http' scheme. Here is svn --version for that: svn, version 1.8.1 (r1503906) compiled Jul 24 2013, 11:57:22 on i686-pc-linux-gnu Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme -- Problem does not occur when using the 'file' scheme which makes sense. First thing to try is to test this with the latest client release, 1.8.3 (this uses serf 1.3.1 internally). A lot of connection-related bugs have been fixed already [1]. I have seen each of the following results when running the same command: svn: E120104: ra_serf: An error occurred during decompression svn: E160004: Corrupt representation '489 681 46 46 a2a7fa5ef17fb3ca svn: E070014: Can't read file '/opt/local/csvn/data/repositories/www/db/revs/0/489': End of file found And sometimes the command works successfully. Running svnadmin verify on the repo shows no problems. Hmm, that seems something different than what I'm seeing. In my case, I just got the decompression error, but no reference to a corrupt representation or a corrupt rev file. Are you sure that you can't reproduce this when executing the exact same command with file:// (which should read the same rev file)? And the error doesn't reproduce always, but only some of the time? I can reproduce this with several repos created by the new version 1.8.1 on the server. But other new repos do not cause it to happen. So far all of the existing repos do not cause the problem to occur. Format number from repo/db/format is 4 for existing and 6 for new repos. Hope this helps. Strange. As I said, first try with a 1.8.3 client, and see if it reproduces. Then, perhaps you can also update your
Re: Error during 'svn export' over http with serf 1.3.1
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
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)
