VcsEventWidget + Slow Mercurial Log

Andreas Pakulat apaku at gmx.de
Fri Jan 15 15:00:25 UTC 2010


On 15.01.10 15:47:23, Fabian Wiesel wrote:
> 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.

Uhm, but how'd you do that without knowing the whole history? This is not
even possible in svn with its purely linear revision numbers, in git with
the hashes there's no way to know where the "end" could possibly be.

> 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.

Its assumed that log already follows copy/renames and personally I never
needed it in another way, but yeah maybe an option to choose that might be
useful.

Andreas

-- 
Never reveal your best argument.




More information about the KDevelop-devel mailing list