attn folk doing reviews.

[Robert Collins]

On Mon, 2006-01-23 at 12:43 +1100, Martin Pool wrote:
> On 23 Jan 2006, Robert Collins <robertc at robertcollins.net> wrote:
> > Two things... what do you think of some review guidelines as an aid to
> > memory on the wiki ? I think the peer review thing is working well, but
> > that will make it clear to folk submitting code what we are looking for.
> 
> There are already some in the HACKING file.  More guidelines would be
> good.  Either place is OK, but preferably it'll not be spread across
> both.  I'd slightly prefer to add more detail there and post an excerpt
> with pointer to the wiki.
> 
> > Secondly, I've noticed a couple of times though is that new methods are
> > not getting @needs_read_lock or @needs_write_lock decorators. Generally
> > speaking I think any method in the WorkingTree, Branch and Repository
> > classes will need such a decorator *unless* its 
> >  * a trivial wrapper. Note that a wrapper/convenience function that
> > mutates anything will almost certainly need needs_write_lock.
> >  * unrelated to the persistent storage of the object.
> > 
> > I.e. most recently the fileid_involved methods - they read the inventory
> > weave, and they dont take out a transaction themselves, and neither does
> > self._get_inventory_weave().
> 
> Perhaps needing these decorators on almost all methods suggests an
> underlying problem?  Perhaps we should reconsider having the lock held
> for the lifetime of the object?

Perhaps. I think the tension is coming from having branch exist across
transactions, but its very convenient as a user to not have to worry *by
default* about transactions.

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/20060123/af4c919f/attachment.pgp