lock-breaking ui

[Robey Pointer]

On 27 Feb 2006, at 22:12, Jan Hudec wrote:

> On Mon, Feb 27, 2006 at 18:54:09 -0800, Robey Pointer wrote:
>>
>> On 26 Feb 2006, at 12:30, James Blackwell wrote:
>>
>>> On Mon, Feb 20, 2006 at 10:59:38PM -0800, Robey Pointer wrote:
>>>> Breaking locks should be very rare, and have some warnings  
>>>> associated
>>>> with it.  It comes with the explicit risk of branch corruption.   
>>>> (The
>>>> only time I ever had to break arch's locks were due to bugs in  
>>>> arch's
>>>> interaction with gpg.  Aside from that, I probably would've  
>>>> never had
>>>> the need to break locks.)
>>>
>>> Definitely not rare. I get one or two requests a month for how to
>>> break
>>> locks. I had one yesterday, in fact.
>>
>> This sounds like a bug in bzr, then. :(  Bug reports of "this is what
>> I did to get a dangling lock left behind" would probably be useful.
>>
>> IMHO, there's no reason we can't make lock-breaking be a rare  
>> operation.
>
> Some things that leave stale lock behind are not bzr's fault. Most  
> common is
> of course a network connection failing.

I would consider that "rare", though.  What we want to avoid is  
leaving dangling locks just because the user hit control-C or mis- 
typed an option.

Arch used to leave dangling locks whenever I had forgotten to start q- 
agent for signing a commit, and that used to drive me absolutely  
batshit.  You really don't want users to consider "break-lock" to be  
part of their normal workflow.

robey