Hi,
recently, I tried to commit 2 versions of a huge file (6-7 GB) to a
Subversion repository. Both commits worked fine, but after the second one, I
could no longer access the repository with the standard svn client. Running
"svnadmin verify" on the repository resulted in the same error message I got
from the svn client:
svnadmin: Reading one svndiff window read beyond the end of the
representation
After the first commit, "svnadmin verify" on the repository still worked
fine. Digging a bit deeper, it turned out that it's not the repository itself
which is corrupted, but it's the svn client which gets confused by the
repository contents (possibly on 32 bit machines only).
This happend with Subversion 1.6.12 on Debian Squeeze x86, but I could
reproduce it with 1.7.1 as well.
Recipe to reproduce:
$ svnadmin create repo
$ svn co file://$PWD/repo wc
Checked out revision 0.
$ dd bs=1024k count=5000 if=/dev/urandom of=wc/largefile
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB) copied, 921.329 s, 5.7 MB/s
$ svn add wc/largefile
A (bin) wc/largefile
$ svn ci -m '' wc
Adding (bin) wc/largefile
Transmitting file data .
Committed revision 1.
$ echo foo >> wc/largefile
$ svn ci -m '' wc
Sending wc/largefile
Transmitting file data .
Committed revision 2.
$ svnadmin verify repo
* Verified revision 0.
* Verified revision 1.
svnadmin: Reading one svndiff window read beyond the end of the representation
$
The problem is that subversion/libsvn_fs_fs/fs_fs.c:read_rep_line()
correctly parses the size of the base revision for r2 as a 64 bit number,
but then stores it in an apr_off_t which is 32 bits on my machine.
The attached patch fixes the bug for me. Does anybody see a problem with it?
Could somebody please commit it or should I open an issue in the tracker?
Thanks,
Martin
Received on 2011-11-29 15:02:05 CET