[MERGE] (bug #172970) Change Branch.pull to need to generate_history less often.

John Arbash Meinel john at arbash-meinel.com
Fri Nov 30 05:05:10 GMT 2007


This addresses some of the problems for bug #172970. It doesn't address
all of them, so I'm not considering this a --fixes lp:172970.

Basically, generate_revision_history() is an expensive call, and is extra
expensive in Branch6 formats.
Branch6 does require that we have revno available, and we only really have
that (at the moment) when we have the targets last-revision value. There
are a couple ways we could cache, or search the graph to make revno a bit
cheaper to determine (rather than doing the full generate_revision_history
call). But they all take a bit of work.

And while people might sometimes do "bzr pull -r -2", the most common case
is to pull the tip revision.

I suppose we could close 172970 and re-open it that "bzr pull -r XXX"
is slow.

One possibility is that we could still use iter_reversed_left_history, but
just count backwards from the tip revno. It means we might iterate all the
way back to NULL_REVISION and find out that the revision_id isn't in the
mainline (again, common case is that it is), but you can even pull from a
revision which isn't in the ancestry of a branch. (bzr pull -r revid:XXXX source
is really just pull to a revision that you can get access to, it doesn't
have to be in the branch you reference.)

There is still more which needs to be done, but for a treeless branch,
this drops the "bzr pull" time from 43.6s down to 17.8s for me. (About a
2x gain.)

As mentioned in the bug, it could really be a 1s test. (heck if we special
cased the NULL_REVISION it would probably be a whole lot faster for my
test.)

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 4989 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20071129/3c1922f3/attachment.bin 


More information about the bazaar mailing list