subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Stieger <>
Subject Re: svnsync/diff zlib - trying to understand/figure out an error
Date Thu, 11 Dec 2014 15:48:16 GMT

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.

> - 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.


View raw message