lock-breaking ui

[John A Meinel]

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.

Now, I think we use try/finally, so as long as the connection stays up
even if we fail to perform some action, the remote branch should be
unlocked.

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

Arch had the advantage that the act of breaking the lock actually
removed whatever data the client was adding. I'm guessing that on
Windows, you wouldn't be able to break a held lock anyway. (I know you
can't do anything to an open file. Can you rename a directory if the
file underneath it is open? Maybe, but I'm pretty sure you can't delete it).

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.

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/8072d184/attachment.pgp