Speedup with history-db

[Eli Zaretskii]

> Date: Tue, 31 May 2011 14:40:41 +0200
> From: John Arbash Meinel <john at arbash-meinel.com>
> CC: bazaar at lists.canonical.com
> 
> > With the plugin, it displays the same, but
> > then goes on displaying all the rest of the revisions all the way to
> > revno 1!  It's a small wonder that 16.6 seconds are taken by this:
> > 
> >      115006   0  16.6014      2.7581   <bzrlib\log.pyo>:1708(log_string)
> > 
> > So this change in the output of "bzr log" caused by the plugin is
> > really something to look into.
> > 
> 
> Looking at the code, I think this is only triggered when the
> 'stop_revision' is not a mainline. Certainly something that can be dug
> into, but not a huge concern right now for me. I'll try to put in a hack
> to at least fall back to the original if I can detect a case I don't handle.

Fair enough.  The only use cases that really bothers me is this

    bzr log --include-merges -c REVISION

This is something I do quite a lot, because I like to know what went
into merge commits and people tend to not describe that adequately in
the log message of the merge.  This command does not mention dotted
revnos, only revisions on the mainline (I do understand that -
--include-merges is a reference to dotted revnos in disguise).  The
output of the above command must be accurate, otherwise I will be
forced to use --no-plugins, because I cannot trust the output.  It
would be nice if it could be fast as well, but accuracy is more
important.

Thanks.