[PING][MERGE] Waiting on locks

[David Allouche]

Matthieu Moy wrote:
> Martin Pool <mbp at canonical.com> writes:
> 
>> I was going to say infinite too, but I think Matthieu's argument is
>> compelling - it should be finite by default.
> 
> For the user, "infinite" and "sufficiently long" doesn't change much.
> In an interactive use, I'd have killed bzr much before waiting for 5
> minutes (or, say, 10, or whatever).

I think it depends very much on the context and how much information bzr
gives you.

For a single-writer branch, the lock contention either means the user
has some other operation in progress, or it is a stale lock. Giving
details on the lock allows the user to diagnose and if necessary break
the lock or abort the other operation. In most case, the long timeout
will save the user the trouble of starting write operation again.

For multiple-writers branch, lock contention likely means that somebody
else is comitting/pushing the same branch. In that case, the requested
write operation is likely to fail when the user eventually gets the
lock, but waiting for the lock and _then_ failing is a useful way to
notify the user when to initiate corrective action (likely, merge or
update). Giving lock details also helps in diagnosing problems (John,
have you really been committing for 2 hours?).

As long as bzr gives useful information to the user, instead of blocking
silently (as it used to do), a long time-out is useful.

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.
-- 
                                                            -- 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/20060905/5744e872/attachment.pgp