[PING][MERGE] Waiting on locks

[David Allouche]

Marius Kruger wrote:
> +1 for 5 min default timeout:
> 
>     The cronscript use case is interesting, but I think it is rare enough
>     that the default should be to block if not forever, then at least for a
>     "very long time", like 6 hours.
> 
> * cron scripts are definitely not isolated/rare use cases

I would be the last person to discount the importance of bzr behaving
right in automated systems. But in my experience, finding the little
trick (a config option for example) to make it behave as expected in
such context is acceptable, while it's not acceptable to deliver the
best out-of-the-box behaviour for interactive use.

It is my opinion that retrying to take the lock for what is a "very long
time" in interactive use is the right out the box behaviour.

> * I'd rather let it timeout and maybe retry later 
>    (could be specified with commandline parameter like --max-retires=3)

When I said "timeout" I actually meant "time during we'll actively retry
taking the lock periodically", for example every 10 seconds.

> * If nothing happened in 5 minutes, something is probably wrong,
>   and would probably require the user to retry or do something.

The point of automatically retrying for a long time is to save the user
the trouble of retrying manually.

> * Infinity is a very long time. Non terminating tasks is a big no no,
> especially on servers.

If you require reliable automated operation, you need a strategy for
breaking stale locks anyway. In all other cases, the lock will
eventually be released so it's not going to block forever.

> * 6 hours is way too long too, the script must actually fail/[terminate
> with message] if something is wrong
>   and if nothing happened in 5 minutes something is probably wrong.

Agreed. That's why the lock taking code must describe what it is
blocking on, so the interactive user can take corrective action, or find
that it is just normal contention and do something more productive while
bzr does the busy work of checking when the lock is released.

> +1 for globally/user configured timeout
> * seems like the timeout differs per user case rather than per branch:)
> * a specific site (like at home or at work) has certain network constraints
>   (like dial-up or broadband) not the branch.

I have no strong opinion on that. I believe the bzr configuration system
is flexible enough to provide both a global option and per-branch
setting at a very small cost.

-- 
                                                            -- ddaa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060909/4c629ce7/attachment.pgp