lock-breaking ui

[Robey Pointer]

On 20 Feb 2006, at 16:03, John A Meinel wrote:

> Robert Collins wrote:
>> On Mon, 2006-02-20 at 09:07 -0600, John A Meinel wrote:
>>> If possible, but I don't know how much it will actually help them.
>>>
>>> I will say that lock holders need to know that they have lost the
>>> lock,
>>> rather than unlocking someone else's lock.

Allow me to back up to this point, because I think this is the real  
issue.

I think if a lock is broken by B while it was still in use by A, the  
branch is probably corrupt.  Because if B breaks A's lock and starts  
to manipulate files, we now have two writers who think they hold the  
lock -- everything after this point is probably moot.

There might be some advantage in noticing that the lock had been  
broken, and being able to mark the branch as corrupted, but I  
wouldn't worry about making that atomic.  (Maybe when B fails to  
unlock, it can leave behind a file ".bzr/corrupted" to force someone  
to run 'bzr check' before any other write operation can happen.)

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.)

robey