lock-breaking ui

[John A Meinel]

Robey Pointer wrote:
> 
> 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.
> 

Well you may not be thoroughly doomed. But yes, it is likely to break
lots of things.

Actually, not really, you probably can just pop a couple of revisions
off of revision-history, maybe remove them from revision-store/* and
then things will probably sort themselves out.

It means your branch may end up confused about what state it is. But you
have a very good chance that just backing up a little bit will fix the
problem. I do believe that 'bzr check' would find these problems. Since
it should be checking the inventory and making sure that the weaves
contain all revisions that are being referenced.

But I wouldn't mind if when bzr detects that someone broke its lock from
underneath it, that it marked the branch as possibly corrupted, and a
'bzr repair' needs to be run to make everything kosher again.

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

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/2db16501/attachment.pgp