lock token

[Robert Collins]

On Wed, 2007-02-07 at 15:39 +1100, Robert Collins wrote:

> > I don't feel like I have a very solid understanding of the problem here.  Is
> > there a test case demonstrating the problem?

...


More detail on this follows, with a proposed approach to implementing.

We have two possible cases for RemoteBranch needing to use a lock token:

 _ensure_real() when the RemoteBranch is already locked
 lock_write() when there is already a _real_branch

The former should grab a token from self, and use it to immediately lock
the real branch; if the real branch does not lock successfully, it
should make sure that self._real_branch is not set, because the remote
and local state is not synchronised, indicating a problem, and the local
owner of the branch thinks the branch is already locked. Additionally,
RemoteBranch._ensure_real() should start by calling
self.repository._ensure_real() - which will setup a real repository for
the repository, taking care of whatever lock tokens it needs on the way
- and then poke self.repository into self._real_branch.repository, which
will cause methods on self._real_branch to take advantage of
RemoteRepository fast-pathing, even when the RemoteBranch isn't updated
yet.

The latter should invoke a remote method to lock the branch, which will
return a token. That token should be used to lock self._real_branch. If
the lock fails, the RemoteBranch should unlock itself and its repository
(just as Branch.lock_write does), before throwing an error.

RemoteRepository needs exactly the same logic applied to it.

lock_write on both Branch and Repository needs to be altered to support
lock_write(token="xxxx")

this should pass down to the controlfiles the token, which finally will
be given to LockDir.lock_write. This should cause the lock to be
considered 'locked' if and only if the token can be verified - i.e. by
reading the data from disk and ensuring it generates the same token.
When this LockDir is unlocked, it should /not/ alter the disk lock data,
instead it should just consider itself unlocked. This is an API that
cannot be supported on branches that are not transport-safe, that is,
pre-metadir branches cannot support this, and we should not try to make
them support it. It is an API change, but one we only need for a subset
of implementations, so I think an _implementations test for both Branch
and Repository is needed, something like:

def test_lock_token(self):
    """Test that the branch can be locked with a token."""
    branch = self.make_branch()
    branch_b = branch.bzrdir.open_branch()
    token = branch.lock_write()
    try:
        try:
            branch_b.lock_write(token=token)
        except errors.TokenLockingNotSupported:
            return # not a failure or skip: optional api element.
    finally:
        branch.unlock()

Cheers,
Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- 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/20070208/e74d6b28/attachment.pgp