VcsEventWidget + Slow Mercurial Log

Fabian Wiesel fabian.wiesel at googlemail.com
Fri Jan 15 14:47:23 UTC 2010


On 15/01/10 12:34, Andreas Pakulat wrote:

>> The other way to solve it would be in the VcsEventWidget (or the
>> VcsEventModel):
>> Instead of loading the full log, one only loads the necessary parts.
>> Maybe the first 100 and the last one  and make a guesstimate about
>> VcsItemEventModel::rowCount().
>> When GUI requests other parts of the VcsEventModel, one tries to find
>> the correct blocks.
>> Similar problem, how does the GUI behave, if I change the rowCount() on
>> the fly?
>> More work, quite a fair amount of more code, but definitely more
>> scalable. But you could say it is a work-around.
>>      
> This could be possible with canFetchMore/fetchMore in the model API, but
> I've only ever seen that used for fetching the children of a node thats
> being expanded...
>
> This should work, we don't need to guess the rowCount, the model could just
> ask the plugin for 20 revisions starting from HEAD. Then when it receives
> the 20th, it asks the plugin 20 revisions starting from this one. Each time
> it receives data the existing mechanism is used to add the data, which
> adds the rows and lets the view know. With the addition of a "stop" button
> in the view one could even allow to cancel this process by the user, so we
> don't fetch all 40K revisions, but instead stop at 20K because the user
> only wants to look at the 19640th revision or so :)
>
>    

Sure, that would work. But the idea behind the estimate for the row count
was to allow the user to jump to the last revision, without having to
wait for the whole history to be loaded.

I thought, that would be the second most likely task I would perform.
That's how I would proceed to know, where a file has originated from.
Which reminds me, the IBasicVersionControl::log() has no option for 
follow-copy/renames.
This might be handy.

Fabian





More information about the KDevelop-devel mailing list