Stefan Sperling wrote on Wed, Jul 13, 2011 at 15:59:36 +0200: > Hi all, > > while repairing some bad repository breakage we noticed that > svnadmin verify does not check whether offsets mentioned in > rep-cache.db point to valid reps. > > In some cases I had to append repaired reps after the changed-paths > section in revision files and leave broken reps in place to avoid > adjusting offsets everywhere. > > So now 'svnadmin verify' runs fine. But when the rep-cache is > referred to during commit we can still run into reps that are broken. > > Obviously we'll either have to fix up the rep-cache as well, > or simply delete it. But the point is that 'svnadmin verify' > does not complain. > > Would it be feasable to add this as a separate pass of 'svnadmin verify'? > Should I file an issue about this? > > For instance, good output could look like this: > > $ svnadmin verify repos > * Verified revision 1. > ... > * Verified revision N. > * Verified rep-cache. > > $ > > And errors like this: > > $ svnadmin verify repos > * Verified revision 1. > ... > * Verified revision N. > svnamdin: rep-cache entry '8fe47fa166154fc6e7f2e78366591c470ba75cf7' is > invalid > svnadmin: Malformed representation header > > $
Implemented and committed. Output looks like this: [[[ % sqlite3 r1/db/rep-cache.db "update rep_cache set offset = offset + 1 where offset = 550;" % $svnadmin verify r1 * Verified revision 0. * Verified revision 1. DBG: fs_fs.c:7789: verify_walker(): got r1/0 DBG: fs_fs.c:7789: verify_walker(): got r1/551 svnadmin: E160004: Corrupt representation '1 551 42 30 (null) e2ca5cc8621b52accf604fbf1ef27144bdf89542 (null)' svnadmin: E160004: Malformed representation header at r1/db/revs/0/1:556 ]]] Notification will follow someday --- see issue #3958.
