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.
