Your history is toast. Stop burning cycles. Lock your working server, Take
clean working copies of the important branches if you can get them, the clean
working copies, import them to a new server, and start with a much lighter
working repository.
And *stop* putting binaries in the same reposit
The decompression errors only seem to happen when we're sending binary
data. For a couple of years our marketing team were storing all of their
files in subversion and this seems to be the vast majority of the revisions
I'm having to fix with fsfsverify.py. So it could possibly be that they
were us
On 30.08.2019 15:14, Michael Ditum wrote:
> Hi Brane,
>
> Thanks for the reply. Interestingly Daniel's reply had given me the
> idea to try pretty much what you suggested and I gave it a go this
> morning and it seems to be working.
>
> Stopping svnsync in the right place wasn't hard as i dies as s
Hi Brane,
Thanks for the reply. Interestingly Daniel's reply had given me the idea to
try pretty much what you suggested and I gave it a go this morning and it
seems to be working.
Stopping svnsync in the right place wasn't hard as i dies as soon as it
tried to get the binary diff but before it's
On 29.08.2019 20:49, Michael Ditum wrote:
> Apart from using fsfsverify I also tried recreating the diff by
> creating a Fedora 7 VM, running svnsync on it to copy the repo up to
> that point and then manually committing the file and copying the
> revision over to the copy of my original repo.
Yik
Michael Ditum wrote on Thu, 29 Aug 2019 18:49 +00:00:
> Does anyone have any ideas on how I can fix this revision? As I
> mentioned before, the file gets deleted a couple of revisions later so
> I don't really care about the contents of the revision but I'm
> currently stuck and can't get any fu
t; [mike@tigger svn]$ svnadmin dump svnroot > svnroot.dump
>> * Dumped revision 1.
>> ...snip...
>> * Dumped revision 24950.
>> * Dumped revision 24951.
>> * Dumped revision 24952.
>> svnadmin: E140001: zlib (uncompress): corrupt data: Decompression of
>> svndiff
...snip...
> * Dumped revision 24950.
> * Dumped revision 24951.
> * Dumped revision 24952.
> svnadmin: E140001: zlib (uncompress): corrupt data: Decompression of
> svndiff data failed
>
So it fails on the same revision.
I need to think about this some more.
952.
svnadmin: E140001: zlib (uncompress): corrupt data: Decompression of
svndiff data failed
Mike
On Thu, 29 Aug 2019 at 20:04, Nathan Hartman
wrote:
> On Thu, Aug 29, 2019 at 2:49 PM Michael Ditum
> wrote:
>
>> As we're running a ridiculously old subversion server (1.4.4) o
On Thu, Aug 29, 2019 at 2:49 PM Michael Ditum wrote:
> As we're running a ridiculously old subversion server (1.4.4) on a
> ridiculously old operating system (Fedora 7) I've decided it's time to
> migrate to a new server.
>
Have you tried to do a dump from 1.4.4 and load on a newer version of
Su
Hi,
We've been running a subversion server since 2003, over the years we've
come across the svndiff decompression error numerous times, it's almost
always when we're committing binary files to the repository. Historically
we've always noticed it quite quickly and fixed the issue by deleting the
of
Philippe Busque wrote on Mon, Jul 25, 2011 at 15:05:29 -0400:
> I need to know if there's a way to unpack a single shard so that I can
> run this script on the faulty revision and repair it, without having to
> either unpack the whole repository or do a dump / load.
>
> Thanks
The shards are inde
rsion/repository/filename@233985
svn: Decompression of svndiff data failed
So far, all my search pointed to a corruption performed by mod_dav_svn
and the only solution has been to run a script called fsfsverify.py
I cloned my repository, downloaded this script and ran it, only to find
out it won'
On Thu, 23 Jun 2011 22:34:54 +0200, Stefan Sperling wrote:
On Thu, Jun 23, 2011 at 08:50:05AM +0200, martin wrote:
Hi all,
I've searched the list and could not find an answer to this.
I've run into the dreaded "Decompression of svndiff data failed"
problem.
Running http:/
On Thu, Jun 23, 2011 at 08:50:05AM +0200, martin wrote:
> Hi all,
>
> I've searched the list and could not find an answer to this.
>
> I've run into the dreaded "Decompression of svndiff data failed"
> problem.
>
> Running http://www.szakmeister.net
On Jun 23, 2011, at 01:50, martin wrote:
> I'm using svn 1.5.1
You should really upgrade. Many bugs were fixed in later 1.5.x versions, and
even more in 1.6.x. The first 1.7.x test release was just published, so you can
expect 1.7.0 final to be released before too long, at which time support f
Hi all,
I've searched the list and could not find an answer to this.
I've run into the dreaded "Decompression of svndiff data failed"
problem.
Running http://www.szakmeister.net/fsfsverify/utility trying to fix it
I end up with a string of errors.
So far I've s
vys...@oksystem.cz wrote on Tue, May 10, 2011 at 12:20:36 +0200:
> I found "Decompression of svndiff data failed" message only in one
> file in sources - /libsvn_delta/svndiff.c - in the zlib_decode
> function. So, probably data in the repository in the file for this
> revi
On Tue, May 10, 2011 at 12:20:36PM +0200, vys...@oksystem.cz wrote:
> Hello.
>
>
> I use svn co to checkout my repo. All worked fine for a while, but today I
> get error
>
>
>
> Decompression of svndiff data failed: no size
What versions of Subversion are you run
Hello.
I use svn co to checkout my repo. All worked fine for a while, but today I get
error
Decompression of svndiff data failed: no size
every time I try to do svn co.
I found out that I got these errors not only from svn co, but also from
svnsync, svnadmin dump, etc.
This happened
One other thing you could try is fsfsfixer (available in contrib/ in
trunk), which Julian Foad added a few weeks ago.
I have not used that tool or reviewed it.
Bastian Ugimachi wrote on Thu, Apr 21, 2011 at 14:52:33 +0200:
> 2011/4/21 Daniel Shahaf
> > Bastian Ugimachi wrote on Thu, Apr 21, 2011 at 14:17:00 +0200:
> > > The intersting thing is that the ID in my error message belongs does not
> > > belong to the same representation as the part extracted b
2011/4/21 Daniel Shahaf
> Bastian Ugimachi wrote on Thu, Apr 21, 2011 at 14:17:00 +0200:
> > 2011/4/21 Daniel Shahaf
> >
> > > >
> > > > I furthermore integrated svn into my IDE (Eclipse Helios) and also
> tried
> > > a
> > > > checkout of the project, of which revision 2 (the corrupt one)
> con
Bastian Ugimachi wrote on Thu, Apr 21, 2011 at 14:17:00 +0200:
> 2011/4/21 Daniel Shahaf
>
> > >
> > > I furthermore integrated svn into my IDE (Eclipse Helios) and also tried
> > a
> > > checkout of the project, of which revision 2 (the corrupt one) consisted.
> > > The process aborts, showing t
2011/4/21 Daniel Shahaf
> >
> > I furthermore integrated svn into my IDE (Eclipse Helios) and also tried
> a
> > checkout of the project, of which revision 2 (the corrupt one) consisted.
> > The process aborts, showing the following error:
> > Get content for 'svn+ssh://
> server.fqdn.com/path/to
Bastian Ugimachi wrote on Thu, Apr 21, 2011 at 12:29:33 +0200:
> the revisions. Applying "./fsfsverify.py -f /opt/maps/svn/maps/db/revs/0/x"
You probably know that, but:
You should have taken a backup before running this.
Bastian Ugimachi wrote on Thu, Apr 21, 2011 at 12:29:33 +0200:
> Strangely, "svnadmin recover /path/to/rep" successfully succeeds:
> svnadmin recover /path/to/rep
> Repository lock acquired.
> Please wait; recovering the repository may take some time...
> Recovery completed.
> The latest repos revi
Hello,
I recently installed a subversion (version 1.6.11) repository on out RHEL 5
system, that I access using ssh+svn protocol. Already after some very few
commits, I ran into the problem of getting the error "svnadmin:
Decompression of svndiff data failed" when performing "svna
[error] [client 10.1.128.18] Decompression of
> svndiff data failed: size too large [500, #185005]
>
> When I tried to do the same activity with svn protocol, I got the below error:
>
> svn: Decompression of svndiff data failed: size too large
>
> The weirdest part is that
ov 16 19:57:07 2010] [error] [client 10.1.128.18] A failure
occurred while driving the update report editor [500, #185005]
[Tue Nov 16 19:57:07 2010] [error] [client 10.1.128.18] Decompression of
svndiff data failed: size too large [500, #185005]
When I tried to do the same activity with svn
30 matches
Mail list logo
