[PING][MERGE] Waiting on locks
John Arbash Meinel
john at arbash-meinel.com
Sat Sep 9 14:58:27 BST 2006
David Allouche wrote:
> 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.
The current code was designed to sleep for 0.5s between attempts.
Certainly if we decide to make the overall timeout variable, we could
make the retry time variable too.
>> +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.
It is flexible enough. But there are some api issues. (LockDir tries to
look like a plain lock to the Branch/Repository, so that the old format
code doesn't have to be special cased. and LockDir shouldn't manually
reach out to read the lock timeout information from the config file).
So there are some possibilities. I just haven't figured out what the
best api changes are.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060909/a7912cbd/attachment.pgp
More information about the bazaar