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.
Received on 2014-10-20 20:59:31 CEST