corrupt data with svn 1.7.14?
I've reported the following bug in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734163 I first thought it could be due to some problem with the binNMU, but the problem still occurs after downgrading to the original 1.7.14. However I no longer get random behavior, just consistent broken behavior. I don't know whether this is Debian-specific or not. With my private repository: xvii:...www/contents/cine =svn diff -r 51990 index.fr.xml Index: index.fr.xml === Cannot display: file marked as a binary type. svn: E22: Valid UTF-8 data (hex: 73 76 6e 3a 6d 69 6d 65 2d 74 79 70 65 20 3d 20 28) followed by invalid UTF-8 sequence (hex: a8 a5 93 55) with: svn, version 1.7.14 (r1542130) compiled Dec 27 2013, 15:24:53 This problem is reproducible on a second Debian/unstable machine, but not on a 3rd machine, with svn 1.6.12. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: corrupt data with svn 1.7.14?
On 2014-01-04 14:46:54 +0100, Vincent Lefevre wrote: I've reported the following bug in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734163 I first thought it could be due to some problem with the binNMU, but the problem still occurs after downgrading to the original 1.7.14. However I no longer get random behavior, just consistent broken behavior. I don't know whether this is Debian-specific or not. To reproduce it with a public repository: ypig:~ svn co svn://scm.gforge.inria.fr/svn/mpfr/misc/vl-tests Avl-tests/mpfrtests.data Avl-tests/mpfrtests.sh Avl-tests/release-3.1.2-p4 Avl-tests/release-3.1.0-p8 Avl-tests/vfy-data Avl-tests/ReadMe Checked out revision 8727. ypig:~ cd ./vl-tests ypig:~/vl-tests svn diff -r8726 ReadMe Index: ReadMe === Cannot display: file marked as a binary type. ) H(mime-type = (H( Index: ReadMe === --- ReadMe (revision 8726) +++ ReadMe (working copy) Property changes on: ReadMe ___ ypig:~/vl-tests svn diff -r8726 ReadMe Index: ReadMe === Cannot display: file marked as a binary type. svn: E22: Valid UTF-8 data (hex: 73 76 6e 3a 6d 69 6d 65 2d 74 79 70 65 20 3d 20 28 48) followed by invalid UTF-8 sequence (hex: 87 bb 01 d5) Downgrading to 1.7.13 solves the problem. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: corrupt data with svn 1.7.14?
On 1/4/14, 6:14 AM, Vincent Lefevre wrote: On 2014-01-04 14:46:54 +0100, Vincent Lefevre wrote: I've reported the following bug in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734163 I first thought it could be due to some problem with the binNMU, but the problem still occurs after downgrading to the original 1.7.14. However I no longer get random behavior, just consistent broken behavior. I don't know whether this is Debian-specific or not. To reproduce it with a public repository: ypig:~ svn co svn://scm.gforge.inria.fr/svn/mpfr/misc/vl-tests Avl-tests/mpfrtests.data Avl-tests/mpfrtests.sh Avl-tests/release-3.1.2-p4 Avl-tests/release-3.1.0-p8 Avl-tests/vfy-data Avl-tests/ReadMe Checked out revision 8727. ypig:~ cd ./vl-tests ypig:~/vl-tests svn diff -r8726 ReadMe Index: ReadMe === Cannot display: file marked as a binary type. ) H(mime-type = (H( Index: ReadMe === --- ReadMe (revision 8726) +++ ReadMe (working copy) Property changes on: ReadMe ___ ypig:~/vl-tests svn diff -r8726 ReadMe Index: ReadMe === Cannot display: file marked as a binary type. svn: E22: Valid UTF-8 data (hex: 73 76 6e 3a 6d 69 6d 65 2d 74 79 70 65 20 3d 20 28 48) followed by invalid UTF-8 sequence (hex: 87 bb 01 d5) Downgrading to 1.7.13 solves the problem. One of the Debian maintainers sent a similar email to the dev@ list. I'll be replying there. Link to the original message in the thread: https://mail-archives.apache.org/mod_mbox/subversion-dev/201401.mbox/%3C20140104152012.GB2984%40cerberus.jamessan.com%3E
Seeking help for E000054: Error retrieving REPORT: Connection reset by peer
Hello, 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 AdirA/subdir1 AdirA/subdir2 AdirA/subdir3 AdirA/subdir4 svn: E54: 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: E13: 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). Thank you, Mojca