lock-breaking ui (was Re: transport lock methods)

[Martin Pool]

On Thu, 2006-02-16 at 20:29 -0600, John A Meinel wrote:
> Robert Collins wrote:
> > I think we should remove the lock methods from transport because having
> > transport specific locks leads to bugs : we dont have cross-transport
> > compatibility.
> > 
> > I think we should do this for 0.8. Thoughts?
> > 
> > Rob

They should certainly be deprecated and not used by new formats.

I think it's fairly common to use only one particular protocol to write
to a branch, and the transport locks at least give some protection
against that.  

There are several options

 0: leave them as is, using protocol-specific locking

 1: change them to use LockDirs instead - will give protection between
new clients using old branches

 2: use both LockDirs and protocol-specific methods: will give
transport-specific protection for old clients, and better protection for
new clients

 3: remove them entirely, so new clients on old branches have no
protection

Of these I prefer 2, and then 0.

It's possible we could actually use a single lock dir which satisfies
both types of client -- ie by existing it blocks out attempts to create
with O_EXCL.

I think we can avoid getting tied up by older clients by always taking
the downlevel lock first.

> I think we should move to LockDir for 0.8, which would get rid of
> transport specific locks. We only had transport specific locks because
> we *couldn't* have OS locks over sftp.
> 
> By the way, have we worked out any of the ui for breaking locks?

Robert and I talked a little, and thought this:

* users or shell scripts should never need to take fine-grained locks
(the shell interface isn't so fine-grained as to make it useful), so all
they need is to display or break locks

 * it should be possible to show the descriptive information of a lock,
or to break it

 * when interactively breaking the lock the user should probably be
shown the descriptive information first.  there's a possible race here
when someone else acquires the lock between the user seeing it and
deciding to break it

 * it should be possible for the lock holder to discover that they've
lost the lock; it's not practical to asynchronously signal this to them
but they could discover it when they try to freshen or release the lock

 * if the lock is not acquired by operations within a timeout, they
raise an exception.  we could possibly catch that and prompt the user to
break the lock if they think it's stuck.

-- 
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060220/54eb707b/attachment.pgp