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!
