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
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
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
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
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.
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
igger 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 data faile
.
> * 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.
min: 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) on a
>> ri
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
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
/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't support
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
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://www.szakmeister.net
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 seen:
- Error
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
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 running on your server and the clients?
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
revision somehow corrupted during
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
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 svnadmin dump
/path
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.
2011/4/21 Daniel Shahaf danie...@elego.de
Bastian Ugimachi wrote on Thu, Apr 21, 2011 at 14:17:00 +0200:
2011/4/21 Daniel Shahaf danie...@elego.de
I furthermore integrated svn into my IDE (Eclipse Helios) and also
tried
a
checkout of the project, of which revision 2 (the
Bastian Ugimachi wrote on Thu, Apr 21, 2011 at 14:52:33 +0200:
2011/4/21 Daniel Shahaf danie...@elego.de
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
] [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 protocol, I got the below
24 matches
Mail list logo
