Hello,
On 11/12/2014 14:06, Marc Verwerft wrote:
While creating a replica of an existing repository using svnsync, I
bumped into a problem that I'm trying to figure out.
In short, I don't think SVN is to blame but that we've got a corrupted
transaction/file somewhere. I'm just trying to figure out the options
and next steps to fix this.
This is what happens: we create an empty repository and start syncing it
with a remote one. At a certain transaction, we get the error
'Decompression of svndiff data failed' and the syncing stops. If I look
at the files in that transaction (using svn log --verbose) I only see
two files with a .java_ extension. I suspect that these are text files,
maybe leftovers of a text editor.
I've done some investigations on internet and had a look at the
subversion files, especially subversion/libsvn_delta/svndiff.c. The
error is linked to the 'uncompress' function of zlib. As I understand
it, svnsync is replaying all the transactions from the original
repository - or at least as much as possible giving the properties of
the revision, etc.
My questions:
- I suspect this error is related to a corrupted (or missing) file. Is
this correct?
- Is zlib used for some other purpose within svn that I don't know about
(except for zip/unzip of a file)?
- is there any way to figure out which file in that transaction is
giving this error? Or see the 'contents' of the transaction in full?
svnsync doesn't seem to have a verbose mode that tells what exactly it
is doing
My first approach would to check if svnadmin verify on the source throws
any error, or if svnadmin dump / svnrdump dump return a dump. And if you
are there you could just as well create the mirror repository using
hotcopy/dump and do svnsync init --allow-non-empty.
Regardless of that, the dump will have the contents of the revision, so
will the actual revision file.
I am aware of the following compression related issues in serf when
going over http, but you wrote nothing that would hint to that..
Fix issue #152: CRC calculation error for gzipped http reponses > 4GB.
https://code.google.com/p/serf/source/browse/tags/1.3.8/CHANGES
https://code.google.com/p/serf/issues/detail?id=152
- Can I trust the output of 'svn diff --summarize? Since that invokes
the same file/library (svndiff.c) as svnsync.
It would look at what happened in the rev, yes.
Andreas