[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Testers wanted for FSFS svnadmin recover feature (r23595)

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-03-07 10:35:14 CET

On Wed, Mar 07, 2007 at 01:12:46AM -0800, malcolm@tigris.org 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.

Many thanks,

  • application/pgp-signature attachment: stored
Received on Wed Mar 7 10:35:32 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.