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
On Thu, Aug 29, 2019 at 4:21 PM Nathan Hartman
wrote:
> On Thu, Aug 29, 2019 at 3:15 PM Michael Ditum
> wrote:
>
>> Thanks for the response, I hadn't tried it! I've just given that a go and
>> unfortunately the dump command failed with...
>>
>> [mike@tigger svn]$ svnadmin dump svnroot > svnroot.
On Thu, Aug 29, 2019 at 3:15 PM Michael Ditum wrote:
> Thanks for the response, I hadn't tried it! I've just given that a go and
> unfortunately the dump command failed with...
>
> [mike@tigger svn]$ svnadmin dump svnroot > svnroot.dump
> * Dumped revision 1.
> ...snip...
> * Dumped revision 2495
Thanks for the response, I hadn't tried it! I've just given that a go and
unfortunately the dump command failed with...
[mike@tigger svn]$ svnadmin dump svnroot > svnroot.dump
* Dumped revision 1.
...snip...
* Dumped revision 24950.
* Dumped revision 24951.
* Dumped revision 24952.
svnadmin: E1400
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
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
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 du
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 c
13 matches
Mail list logo
