lock-breaking ui

[Robey Pointer]

On 21 Feb 2006, at 6:57, John A Meinel wrote:

> Robey Pointer wrote:
>>
>> 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.
>
> Not really. Over a transport like sftp, we could easily have a stale
> lock because of a disconnect, or someone hitting ^C. Or some other
> transient effect, which prevents bzr from unlocking properly.  
> Remember,
> we don't have a server sitting on the other end to clean up for us,  
> same
> as arch.

Right... but in those cases, the lock isn't still in use; it's just  
dangling.

My point is that if the lock is still in use when someone else breaks  
it, you're already doomed.


> So yes, lock breaking should be done with some care. The only real  
> need
> being a network timeout while writing to a remote location.
>
> But part of that is why we are adding the 'details' file. So that  
> we can
> inform the user just who has it locked, and for how long. It makes it
> more obvious if the lock is stale.

Yeah, we're agreed here.

robey