Speedup with history-db

[John Arbash Meinel]

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


...
>> Note that it did find 4 revisions that were not present in the
>> ancestry.
> 
> Is there any way to find out the revision IDs of those revisions?  I'd
> like to see what they are.
> 
>> Counting the whole revision table is stupid. I just committed what
>> should be a fix for that (revno 135).
> 
> Thanks.  This slashed the time significantly, but bzr consistently
> says it imports 4 revisions each time I do a "bzr up" with no new
> revisions available in the remote repo:
> 
>   9.360  fetch up to rev {rgm at gnu.org-20110527071815-pnm36i0e38mb8wte}
>   11.766  history_db post-change-hook took 0.246s (0.002s to get_config, 0.096s to init, 0.148s to import)
>   11.766  Stats:
>   {'num_search_tips': 0,
>    'step mainline': 1,
>    'step mainline added': 4,
>    'step mainline cache missed': 1,
>    'step mainline initial': 1}
>   [ 3688] 2011-05-27 18:06:55.062 INFO: Tree is up to date at revision 104384 of branch bzr+ssh://eliz@bzr.savannah.gnu.org/emacs/trunk
> 
> It looks like something else is at work here.

If you do "bzr log -n0 -r -2..-1" is the new tip a merge that includes 3
new revisions. (So you have a new tip + 3 merged revisions for 4 total
revs?)

I would have thought we would see an immediate "hey you have this tip
imported", but maybe we are missing it somehow, and it is triggering a
re-import of the most recent tip again.

I'll try debugging the code, but I can't say that I've seen that here.

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

iEYEARECAAYFAk3kkb8ACgkQJdeBCYSNAAMyQwCeI7drHthCrFK54HxGRPevROva
2UMAoIY4pcJkAaxALF7X6NXubEymry/q
=pSEI
-----END PGP SIGNATURE-----