On Wed, Mar 07, 2007 at 01:12:46AM -0800, email@example.com wrote:
> Implement 'svnadmin recover' for FSFS, recreating the db/current file
> from information in the rev/ files.
I _have_ tested this, and the algorithm is pretty simple --- But:
I'd really appreciate some level of confidence testing on a few more
repositories, particularly those that are particularly large or
particularly weird (anything converted from another vcs, perhaps).
By definition, this code is only going to be run when it absolutely
needs to work, and probably isn't going to be exercised at all
otherwise, so current test coverage isn't great.
If anyone has a repository that they don't mind running development code
on to test this feature, this is what you need to do:
1. Make a backup of your repository. If you _really_ trust me, just make
a backup of db/current.
2. Optionally remove db/current to prove that we're recreating it properly.
(This will obviously make the repository unusable to any clients).
3. Run "svnadmin recover repo/".
4. Wait, as svnadmin reads all of the revision files. Any writers are
blocked for the duration of recovery.
(It'd be nice to get some timing data here as well. My tests had too
much variability, but it looked like a couple of minutes to recover
against [a mirror of] the main Subversion repository).
5. Check that the new db/current is identical to the old db/current.
Scream if not.
That is all.
Received on Wed Mar 7 10:35:32 2007
- application/pgp-signature attachment: stored