Re: Testers wanted for FSFS svnadmin recover feature (r23595)

On 3/7/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> 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.

I started to run this on my 114285-revision svk depot. The first
thing I noticed was that it seems to not want to be canceled; it seems
to ignore SIGINTS, and I had to kill -9 it to cancel it. I assume
this is intentional?

More disturbingly, despite the message "Repository lock acquired.", I
was able to run multiple copies of svnadmin recover on the repository
at the same time. When I noticed that, I freaked out and killed them
both; I'll run it for real once I do an actual backup of my computer
at home sometime soon.

--dave

-- 
David Glasser | glasser_at_mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org