corrupt data with svn 1.7.14?

2014-01-04 Thread Vincent Lefevre
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?

2014-01-04 Thread Vincent Lefevre
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?

2014-01-04 Thread Ben Reser
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

2014-01-04 Thread Mojca Miklavec
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