[step 01] Imminent MERGE request: 12 steps towards a high performance server

Andrew Bennetts andrew at canonical.com
Thu Sep 14 04:28:30 BST 2006


On Wed, Sep 13, 2006 at 11:32:21AM -0500, John Arbash Meinel wrote:
> Andrew Bennetts wrote:
> 
> I'll try to review them one-by-one. It would have been nice if you
> posted diffs, but I went ahead and did that on my end.

I was going to, but it was getting late I and decided to sleep instead.  Thanks
for putting up with it!

> > As Robert recently posted, we've got a fair few infrastructure changes in
> > support of the work on the high performance server.  There are lots of mostly
> > independent changes, so to ease the reviewing load I've split them into seperate
> > branches.  These branches are essentially a sequence of patches to be applied;
> > I think I'll post bundles for review in individual mails (so that each change
> > gets its own thread for discussion), but first here's an overview of what's they
> > all are, in order:
> > 
> >    http://people.ubuntu.com/~andrew/bzr/cosmetic/
> >      purely cosmetic changes -- docstring tweaks and the like.  Hopefully
> >      nothing controversial :)
> 
> I had never seen the 'ivar' parameter for epydoc. Good to know, I guess.

http://epydoc.sourceforge.net/fields.html is the comprehensive list, if you're
curious.

> > +# TODO: Remove the transport-based lock_read and lock_write methods.  They'll
> > +# then raise TransportNotPossible, which will break remote access to any
> > +# formats which rely on OS-level locks.  That should be fine as those formats
> > +# are pretty old, but these combinations may have to be removed from the test
> > +# suite.
> > +
> 
> Actually, these formats aren't all that old. It is just pre-meta-dir.
> (So 0.7 formats). I think we still have a few more months where we
> promised to support them. I would love to get rid of the
> lock_write/lock_read members. I just don't remember when we can actually
> do it. (6 months since 0.8?)
> 
> 
> So +1 to 'cosmetic'. Just the small comment about why lock_{read,write}
> needs to stay for now.

Fair enough.  I've added the comment; here's the incremental diff.

=== modified file 'bzrlib/transport/sftp.py'
--- bzrlib/transport/sftp.py    2006-09-13 10:36:03 +0000
+++ bzrlib/transport/sftp.py    2006-09-14 03:26:10 +0000
@@ -21,7 +21,8 @@
 # then raise TransportNotPossible, which will break remote access to any
 # formats which rely on OS-level locks.  That should be fine as those formats
 # are pretty old, but these combinations may have to be removed from the test
-# suite.
+# suite.  Those formats all date back to 0.7; so we should be able to remove
+# these methods when we officially drop support for those formats.

 import errno
 import os


-Andrew.





More information about the bazaar mailing list