Greg Hudson wrote:
>So, to summarize:
> What we have now: No diagnostic, blocking lock attempt
> mbk's alternative: Diagnostic if we can't get lock, then block
> My alternative: Fail if we can't get lock
> Other alternative: Diagnostic if we can't get lock, then block,
> and print another message when we do get lock
A problem with the current solution that you didn't mention is that it's
really hard to kill svnadmin while it's waiting to acquire the lock
because we ignore SIGINT and SIGKILL. I don't like the "fail if we can't
get lock" approach for the reason you quoted from mbk, but it's not only
a problem when running svnserve from inetd. You can get the same
problems with file:// and svn+ssh://. If you have a busy server that
serves multiple repositories, you don't want to shut down the whole
server just to recover a single repository.
The attached patch implements your "other alternative" above, and also
makes it possible to interrupt svnadmin while waiting for the lock.
Make 'svnadmin recover' print a warning message when it's waiting for
the exclusive lock and a message when the recovery has started. Allow
svnadmin to be interrupted while waiting for the lock.
(setup_cancellation_signals): New helper function.
(recovery_started): New function to inform the user that the recovery
(subcommand_recover): Restore default signal handling before calling
svn_repos_recover2. Call the updated svn_repos_recover2 with
recovery_started as argument.
(main): Use the new setup_cancellation_signals.
(svn_repos_recover2): Add a callback to be called when the recovery
starts and a baton to be supplied to the callback.
(svn_repos_recover2): Call the callback after acquiring the lock.
(SVNAdmin::recover): Update to match updated svn_repos_recover2.
Received on Sun Aug 29 16:11:00 2004
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com