Daniel Shahaf wrote on Wed, Oct 22, 2014 at 11:17:46 +0000: > Stefan Sperling wrote on Mon, Oct 20, 2014 at 20:58:57 +0200: > > 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. > > > > Right, data from the master could be invalid for the slave because of > different txn names, different zlib versions, or any number of other > reasons. > > > 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. > > Or you could delete rep-cache.db, that will keep rep-cache working, > except that revisions younger than current HEAD will not participate > in it. >
s/younger/older/. (That is: new revisions will do rep-sharing only amongst themselves, and will never references anything that is in the rev files that already exist right now.) Daniel > Daniel > (for the record: when backdating HEAD as recommended upthread, one > should _always_ truncate or delete rep-cache.db too, to prevent > corruption down the road from references into the "undone" revisions.)
