[RFC] Enhancement to the "already locked" message

[Martin Pool]

Some indication that we're still waiting and actually polling rather
than hung would be good.  Any mechanism for doing that is better than
none.  But a progress bar counting up to 5m is not so good because
we're not trying to make progress towards waiting that long, but rather
just the opposite.

In non-interactive mode (e.g. cron) we probably want to print nothing at
all: the process will either complete or eventually show an error.

The other thing I would really like if you're going to change this area is
some indication that people can break the lock if they're sure the
existing process is not still running.  That could be as simple as adding
"try using break-lock" to the failure message, and "use Ctrl-C to stop
waiting" when we start waiting.

> And then we just sit there until the lock is available. (If the lock owner
> changes, we will display a new message. This was to handle the case of a busy
> shared repo switching between users).
>
> What I would like to see, is maybe just a '.' everytime we check. So that it is
> clear that we haven't died, we are just waiting.
>
> And then if we have printed out the warning, when we finally acquire the lock,
> we print out something like "Acquired\n".

That sounds good.  To be a bit more fancy you could switch between showing
"checking lock..." and "waiting %ss...".

So we'd end up leaving "acquired" on the screen only if we had to try more
than one time to get the lock?  I guess that makes sense because that's
the same case where we've printed the message about waiting.

I think I would do this with a progress indicator customized to not show a
bar, and use that to repaint these messages.  Possibly the display of
these messages should be split into a different object from the lockdir
itself, or maybe into the ui.  Calling note directly doesn't seem quite
right.

> My big issue is that we don't always get a new progress bar up right away, so
> I'm not sure if it has acquired the lock, and is just busy with the next thing,
> or is still waiting.
>
> I looked into what it would take, and found it isn't trivial. In that we do our
> reporting (by default) to trace.note() which always appends a newline.

I'd like to fix some ui things like this; you can file a bug and assign it
to me if you want.

-- 
Martin