Speedup with history-db

[John Arbash Meinel]

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

On 6/4/2011 9:54 AM, Eli Zaretskii wrote:
>> Date: Tue, 31 May 2011 20:27:01 +0300
>> From: Eli Zaretskii <eliz at gnu.org>
>> Cc: bazaar at lists.canonical.com
>>
>>> Date: Tue, 31 May 2011 16:25:31 +0200
>>> From: John Arbash Meinel <john at arbash-meinel.com>
>>> CC: bazaar at lists.canonical.com
>>>
>>>> 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.
>>>
>>> That still works. The example that fails is:
>>>
>>>  bzr log -rDO.TT.ED..X
>>>
>>> - -c X will always use 2 mainline revisions.
>>
>> Not with the specific revision I somehow managed to find:
>>
>>    bzr log --include-merges -c104363
>>
>> Several other merge-commits I tried indeed work (and are about 15
>> times faster with the plugin than without it).  But this single
>> revision 104363 causes trouble.  Could you please take a look at the
>> above command with that specific revision on the Emacs trunk?
> 
> Same thing happens with revision 104482, committed today to the Emacs
> trunk.  Since the output is relatively short, I will show it here
> (below).  You can see as the output with the plugin shows much more
> revisions than expected.
> 
> Could you please take a look at these two instances?  Other than that,
> the plugin seems to work just great, and slashes the times for "bzr
> log" and "bzr status" by very large factors.
> 
> Here's the output with and without the plugin:
> 
> Without the plugin:
> 
>  D:\gnu\bzr\emacs\trunk>bzr --no-plugins log -c104482 --include-merges --line
>  104482: Eli Zaretskii 2011-06-04 [merge] Support bidi reordering of text cov...
>    104182.1.10: Eli Zaretskii 2011-06-03 Cleanup.  Tested in -nw and verified...
>    104182.1.9: Eli Zaretskii 2011-05-31 src/xdisp.c (single_display_spec_stri...
>    104182.1.8: Eli Zaretskii 2011-05-28 Fix cursor motion across display stri...
>    104182.1.7: Eli Zaretskii 2011-05-28 Fix cursor motion near overlays cover...
>    104182.1.6: Eli Zaretskii 2011-05-28 src/xdisp.c (compute_display_string_p...
>    104182.1.5: Eli Zaretskii 2011-05-21 Discovery of replacing display proper...
>    104182.1.4: Eli Zaretskii 2011-05-14 Remove kludgey save and restore of IT...
>    104182.1.3: Eli Zaretskii 2011-05-14 Text covered by `display' overlays is...
>    104182.1.2: Eli Zaretskii 2011-05-14 Refactoring with bidi_fetch_char test...
>    104182.1.1: Eli Zaretskii 2011-05-10 Started work on reordering display st...

Unfortunately, I cannot reproduce this. I see the short form in both
cases. I'm curious why we would be getting different results.

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

iEYEARECAAYFAk3uGWIACgkQJdeBCYSNAAMjjgCg1rEY2a7W7AUHaZWPpZ1sAF5b
mnUAoI6HmnIH8ElNvgGnst1yfVhp4eDf
=rxZi
-----END PGP SIGNATURE-----