On Mon, Oct 20, 2014 at 08:46:03PM +0200, Stefan Sperling wrote: > On Mon, Oct 20, 2014 at 10:22:05PM +0400, Lev Serebryakov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 20.10.2014 19:07, Stefan Sperling wrote: > > > > > I would recommend you reset the mirrored repository to the last > > > known-good revision (269997?) by moving out of the way all files > > > belonging to newer revisions (in db/revs) and revprops (in > > > db/revprops), running 'svnadmin recover' (this should set > > > db/current to the number of the last known-good revision) > > I've done this three times, each time removing 100 revisions. Result > > the same: before 2 revisions to end "svnadmmin verify" complains about > > "Serialized hash missing terminator". > > > > Now 269999 is clear for sure, as it is very old revision. Iad. yes, > > I've checked "revprops/269/269999", it is properly-formatted prop file. > > > > So, it is NOT problem of revprops, but it is about some other > > (which?) file in repo. > > It's probably a corrupt entry in db/rep-cache.db which every sync > keeps picking up again and again. > > Try the whole procedure again either with rep-sharing disabled > in db/fsfs.conf (enable-rep-sharing = false), or with a copy > of db/rep-cache.db from the master server which you should put > in place before the 'svnadmin recover' step (because entries newer > than the recovered HEAD revision are automatically removed from > the rep-cache during 'svnadmin recover').
Thinking about this some more, it's definitely safer to just disable rep-sharing on the slave. Unless you have a bit-perfect copy of the master repository on the slave it is probably unsafe to copy rep-cache.db between repositories because revision files on the slave might contain data in a different order, in which case rep-cache entries copied from the master would be invalid. If you really want to keep the rep-cache on the svnsync slave you'd have to dump/load or sync again from r0 :-/ Or fiddle with the rep-cache sqlite table directly and remove the bad entry (but you'd have to find that yourself). Disabling rep-caching is a perfectly safe thing to do. It might cause the slave to use a little more diskspace than the master does for future revisions, but there are no other downsides.
