Interrupting pull with ctrl-C left stale locks that cannot be removed - even with bzr break-lock

[Nicholas Allen]

> Well, there are still a few things we could check. Like:
>
> Is there a .bzr/repository/lock/held directory? (And
> .bzr/branch/lock/held, and .bzr/checkout/lock/held).
>   
Yes this directory exists. After rebooting the locks on the working tree 
and branch were removed but the shared repository lock still remains.
> If we have to force it, you can just delete those directories, and it
> breaks the locks. But I'd really like to figure out why bzr is hanging
> first, so we can avoid running into this in the future.
>
> Also, did you hit ^C more than 1 time? In general, we cleanup locks as
> we are exiting, but sometimes it can take long enough that a second ^C
> will kill it during cleanup. (I run into this more when I'm over a slow
> SSH connection)
>   
It could be that I hit it twice because I got impatient ;-)
> It might be nice if we printed: "^C caught, cleaning up locks", or
> something like that. As is, you can hit ^C, and it seems like nothing
> has happened.

I think that would be a good idea. Could you not ignore the control-c 
when cleaning up locks to ensure that they don't get left behind?

But I'm still curious as to why break-lock is still hanging...

Cheers,

Nick