Command-line option for changing block-on-recover behavior considered unnecessary.

Mark Benedetto King <mbk@lowlatency.com>:
> This sounds like a job for a command-line option!

That wouldn't solve the problem, just move the debate to "which mode
should be default?"

Unix programmers have a reflex to make behavior configurable when there is
a controversy about the right thing. This is a good reflex, most of the time.
It's especially appropriate for tools like svnadmin that will be used by
experts to react to unusual situations.

However...making things configurable should not be a substitute for thinking
the design problem all the way through. Every option you add is overhead;
it complicates testing, and has to be documented, and puts an additional
mnemonic load on the user.

In this case, I think we can avoid having an extra command-line option fairly
simply by thinking about the use cases for the tool. It is almost always
going to be used interactively (I'll have more to say about non-interactive
use at the end of this note). Therefore we can count on having a user's
finger above the interrupt button.

So, here's a strawman design that I think might satisfy the run-to-completion
fans without another option:

1. If svn recover sees on startup that it's going to hit a lock, it says
   this:

        The database is locked by processes xxx, yyy, zzz
        Attempting to acquire lock, you can interrupt this with ^C

   Note: listing the blocking processes is not a frill or an option,
   it is necessary. It is how you give the user a way out of the jam
   rather than leaving him suspended wondering what to do next.

2. When it gets the lock, it frobs the terminal mode so DEL and QUIT
   don't work, and says:

        Lock acquired, interrupts will be ignored until completion.

Let's look at how this stacks up against the current proposals as
mbk listed them:

1. What we have now: No diagnostic, blocking lock attempt

It's better than the current state of affairs. Anything would be.

2. mbk's alternative: Diagnostic if we can't get lock, then block

My proposal blocks, but it blocks soft -- it can be interrupted
until you get to the critical phase.

3. Greg Hudson's alternative: Fail if we can't get lock

In the interactive case, I don't think there is much to be gained
by Greg's proposal, because on seeing the lock diagnostic the user
can hit control-C.

But the reverse also applies -- it's easy enough to re-invoke the tool
if it errors out with a lock diagnostic. In fact, his proposal has
the slight advantage that the user doesn't have to hit ^C, but is
dumped straight to a shell prompt and can issue some kill commands
on the blocking processes.

Which design is better depends on how much value you think there is
in having the tool be able to run to completion hands-off.

4. Other alternative: Diagnostic if we can't get lock, then block,
                       and print another message when we do get lock

This is what I proposed above. I think it's a clear improvement over
blocking hard with just one diagnostic.

However, my real point is that adding a command-line option to control
whether or not "svn recover" errors out on startup when it detects a
lock does not really buy you anything in the interactive case -- either
failing out (as Greg proposes) or being interruptible during the attempt
to acquire lock (as I propose) is good enough.

In fact, now that I think about it, I may like Greg's proposal
slightly better than mine. But I'll leave mine on the table in case
the run-to-completion fans like Mark win the argument.

I promised to address the non-interactive case. I think Mark is right
that if we think this one will be at all frequent, it makes a
run-to-completion design like his or mine look better.

But let's ask the next question. If recover is going to be run without
a human watching, do we really want it to block on lock at all?

Probably not. So there may be a good argument for an option after all --
not to control interactive behavior but to control how it works from scripts.
Here's the option:

-f, --force

If this option is specified and svnadmin detects database lockers on recovery
startup, svnadmin will check to see if the calling user has permission to
kill all the blockers. If so, all will be summarily executed and the
caller so notified with a diagnostic. If not, svnadin will complain
about the processes it cannot kill and not kill any blockrs.

-- 
		Eric S. Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org