Stefan Sperling wrote on Tue, Feb 12, 2013 at 18:54:14 +0100:
> On Tue, Feb 12, 2013 at 05:18:01PM +0200, Marius Gedminas wrote:
> > Anyway, this takes care of prevention. What about recovery? Can I fix
> > the three missing revisions manually somehow?
>
> If you can obtain the original revision files from the master
> repository, you can try dropping them into the slave repository as-is.
> That should work, provided the revs are valid on the master.
>
It is not guaranteed to work. It might work under some reasonable
assumptions, but I can think of two cases where it won't work off the
top of my head. That said: try it and see if dump/verify complain.
(bogus offsets due to mismatched enable-rep-caching settings in history,
and issue #4129)
> > Or at least truncate my
> > mirror's history to that point so that I could run svnsync to get just
> > the last month and a half, instead of re-creating the mirror from
> > scratch?
>
> It's possible to reset the repository to some revision rN, yes.
>
> The official way of doing this is to dump the repository from r0
> to rN (using svnadmin dump) and loading this dump file into a freshly
> created repository (svnadmin load).
> Since you're creating an svnsync mirror you should probably run
> 'svnsync init' before loading the dump file, and after loading adjust
> the svn:sync-last-merged-rev revision property on r0 to say 'rN'.
>
Need to truncate rep-cache.db Stefan! (otherwise the invariant on it
won't hold, which can cause lossy corruption)
sqlite3 'delete from rep_cache if revision > N' rep-cache.db
> There is a shortcut if you want to avoid the dump/load cycle, but it
> involves messing with data in the repository so please don't try this
> at home and make backups first! Set the file 'db/current' to rN and
> remove all files in db/revs and db/revprops between HEAD and rN.
> Then run 'svnadmin recover', reset svn:sync-last-merged-rev to rN and
> hope that everything still works. Better try this on a small test
> repository first!
Received on 2013-02-12 19:46:27 CET