Smart server plans for 1.7: effort tests, single RPC for branch opening, server-side autopacking.

[Andrew Bennetts]

Now that 1.6 is finally close, I've been looking ahead a little to what I plan
to do for 1.7.  I'll be taking a two week break during the 1.7 cycle so I don't
want to bite off *too* much though.

The key thing for smart server network performance is still reducing round
trips.  For instance, many of the problems identified at
<http://bazaar-vcs.org/SmartPushAnalysis1.4> are still problems.  So I'm going
to write (and document how to write!) some of what Martin calls “effort” tests:
tests that assert that only a fixed (or at least deterministic) amount of effort
is expended to do an operation.  For the smart server code, this basically means
counting the remote calls (i.e. round trips) that a client makes.
test_remote.py already tests this to some extent on a method-by-method basis,
but I want to get to the point where we can say that e.g. pushing a branch does
N calls, and have a test fail if something accidentally adds more calls.

In case that sounds a bit abstract, here's an example: currently performance
bugs like locking, unlocking and then relocking a branch during a single push
aren't noticed by the test suite.  This should help catch this sort of problem.
In fact, a test that simply tracks lock/unlock calls rather all calls might be a
productive starting point...

That's not the only thing I want to do for 1.7.  In terms of concrete
improvements, I want to do a few things that I think are fairly cheap to fix,
but will help smart protocol performance:

 * using a single RPC to open branches (including the repo and bzrdirs).  This
   will help basically every single smart operation.
 * server-side autopacking.  I previously sent a hackish (and buggy) patch as an
   RFC; I think it shouldn't be too hard to polish this.  It's an interim
   solution (long term a single “Repository.insert_revisions” verb would be
   better than manipulating pack files directly), but it's a cheap improvement.

-Andrew.