Ulrich Eckhardt wrote on Thu, May 19, 2011 at 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.
Files under revs/** are never changed once they're written. (packing
concatenates files but doesn't change their contents)
> 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.
>
FTR, 'svnadmin dump' does take a --deltas option.
Received on 2011-05-21 19:21:10 CEST