Mojca Miklavec <mojca.miklavec.li...@gmail.com> writes: > We have a server running Fedora which has recently been upgraded to > version 20 and it's now running > svn, version 1.8.5 (r1542147) > > I have a bunch of repositories served over http protocol with public > read access and limited commit access. > > Shortly after the upgrade a weird behaviour has been noticed. Running > "svn up" on the top level dir worked ok for me, but running > svn co http://svn.myserver.net/myrepo/dirA > fails with > > A dirA/subdir1 > A dirA/subdir2 > A dirA/subdir3 > A dirA/subdir4 > svn: E000054: Error retrieving REPORT: Connection reset by peer > > The directory "dirA" contains one more file FILE.txt. Checking out any > individual "subdirN" works and the browser is able to display the > contents of dirA. > > Trying to click on FILE.txt in the browser sometimes works (it > currently does) and sometimes shows an XML (like a few minutes ago, > but I'm unable to get it now), saying something similar to the error I > get in console***: > > svn: E175002: Unable to connect to a repository at URL > 'svn.myserver.net/myrepo/dirA' > svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on > '/myrepo/dirA' > > svn: E160004: Additional errors: > svn: E160004: Corrupt node-revision '2-1.0.r137/330061' > > (*** To be precise: this is the error I get after upgrading the > repository to the latest version of SVN, I didn't try to get to this > error before upgrading.) > > The error.log in apache says just: > > [<date>] [dav:error] [pid 3613] [client <ip:port>] Unable to deliver > content. [500, #0] > [<date>] [dav:error] [pid 3613] [client <ip:port>] Could not write > data to filter. [500, #175002] > > I first tried if upgrading the repository would help in any way, so I did > svnadmin dump oldrepo | svnadmin load newrepo > and checking the relevant revision r137 cited in the error all I see > is the following (nothing unusual): > > ------- Committed revision 136 >>> > > <<< Started new transaction, based on original revision 137 > * editing path : dirA/FILE.txt ... done. > * Dumped revision 137. > * editing path : dirA/subdir1/somefile ... done. > > ------- Committed revision 137 >>> > > Checking out the same repository via http on the machine where the > repository itself is located works fine. > > I'm using the same version of SVN (1.8.5) on Mac, but other svn > clients on other OSes have problems as well. > > I tried checking the repository health with > svnadmin verify /path/to/myrepo > and all revisions passed except for some weird error inbetween (the > file rev-prop-atomics.mutex is actually missing, but it isn't present > in any other repository either): > > * Verifying repository metadata ... > * Verifying metadata at revision 1 ... > ... > * Verifying metadata at revision 155 ... > svnadmin: E160052: Revprop caching for '/path/to/myrepo/db' disabled > because SHM infrastructure for revprop caching failed to initialize. > svnadmin: E000013: Can't open file > '/path/to/myrepo/db/rev-prop-atomics.mutex': Permission denied > * Verified revision 0. > ... > * Verified revision 160. > > > I would appreciate any help or debugging hints. If necessary I can > share the repository URL (but I would prefer to share it off-list to > anyone interested in debugging). I can also try to debug myself, but I > need some instructions telling me what to check. I didn't manage to > find anything useful by googling the errors other than figuring out > that the error was part of the code to fix a memory leak > (http://svn.haxx.se/dev/archive-2009-08/0274.shtml).
I've not seen E000054 before but it is EXFULL which is some sort of network error. I suppose the corruption causes some sort of output problem. E000013 is EACCES so you are running verify without write access to the repository. That seems like a perfectly reasonable thing to do so we should probably make the warning less intimidating. It's very odd that Apache is reporting corruption but both the dump/load and verify work without problem. Is the problem reproducible if you restart Apache? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*