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.
Received on 2011-07-13 21:07:44 CEST