[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Empty revisions causing repository failures

From: Ulrich Eckhardt <ulrich.eckhardt_at_dominolaser.com>
Date: Thu, 19 May 2011 10:55:59 +0200

On Wednesday 18 May 2011, Christian Gils wrote:
> I've version 1.5.6 using FSFS stored on ext3 (RHEL 5.4). The repository
> contains about 39k revisions. Revisions 0-36672 are fine and dump
> without any problems. Revisions 36673-8 fail to verify and give the
> following error:
>
> svnadmin: Revision file lacks trailing newline
>
> The same revisions fail to dump and give the following error:
>
> svnadmin: Can't read length line in file 'repo/db/revs/36/3667x
>
[...]
> 36679-HEAD seem to be fine as users have been committing and checking
> out since then. A couple of days ago, however, local checkouts started
> failing with the following error (the rev file listed is going to be one
> of the failing revisions):
>
> svn: Can't read length line in file '/data3/tmp/repo/db/revs/36/3667x'
>
> It looks like certain checkouts hit a file which prompts svn to try and
> read those revisions and subsequently fail.

If a commit doesn't change a file, the data in a previous commit will be
referenced instead, so that it avoids writing the same data over and over
again. When reading, it then looks in previous revisions to locate the file if
necessary. That explains why you can access some parts but not those that were
changed in the lost range.

> As a result we have a
> project which is unusable at the moment. Verification and dumping from
> 36679-HEAD will proceed until it hits a reference back to one of the
> borked revisions and them terminate. I can't even dump both halves of
> the repo and reimport omitting 36673-36678.

IIRC, SVN won't touch these files once they were written. That means that you
can copy just those files from an old backup without disturbing any earlier or
later revisions. Of course you should back up your life data before and
validate the results afterwards.

> I'm kind of stuck as to how to fix this. Can I try to insert mocked-up
> empty revisions in place of the zeroed ones so that svn can proceed with
> dumping the more recent half of the repository or is there a better way
> to do this?

I don't think that works because dumping writes full files, but in order to
get those it might have to read multiple deltas (revisions) from the
repository. If these are not there, you can't restore the full file content.

Good luck!

Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Received on 2011-05-19 10:53:18 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.