RFC: Opening/initializing locked objects

John Arbash Meinel john at arbash-meinel.com
Fri Jan 9 18:20:00 GMT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In looking at some of the traces of remote connections, you can see some
inefficiencies in how we are handling things like locking the remote object.

For example, when creating a new Branch, we actually create the .bzr
dir, lock it for writing, upload the content, then unlock it, and then
start looking around for a Branch to be present in that directory.

I also know that we tend to lock an object as we create it, but then we
return it unlocked to the caller, who then locks it as the first action.

It also would be nice to have a single RPC that could open whatever
branch is present, along with its associated repository, and have
everything primed for writing. So I'm proposing to add a new API, which
is similar to our existing helpers, but does a bit more to combine
things together.

I was thinking to call it Branch.open_locked() with an api of something
like:

def open_locked(self, url, possible_transports=None, containing=False,
		writeable=False):


The "containing" parameter would mean the return value would need to
have a way to give the tail of the URL (as open_containing does now).
I'm thinking to not change the return signature, but just allow the
relpath to always be '' when containing is False.

Instead of 'writeable=False' we could do 'readonly=True', but I felt
that 'readonly=False' wouldn't be as good of an indication that we want
to write as 'writeable=True'.


I was also thinking about the "initialize" functions we have elsewhere.
I don't think we can simply change them to return locked objects,
because of API compatibility concerns. 'create_locked()' would be a good
match for 'open_locked()' and flows a bit better than 'initialize_locked()'.

Alternatively we could add a "create" parameter to 'open_locked', but I
think it needs to describe a format, which is turning it into a bit too
overloaded, IMO.

It would also be a design goal to make functions like
"RepositoryAcquisitionPolicy.acquire_repository()" actually return a
locked object.

This would also end up as an RPC

I'm certainly interested in hearing any feedback people have, before I
spend much time on it.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklnlVAACgkQJdeBCYSNAAM6XACdHxSjgo1XlBXlH53aeRqNbnIH
uBAAnjviFVwACtb3ukMGIaaSwQ5P8Aoo
=26Y/
-----END PGP SIGNATURE-----



More information about the bazaar mailing list