VcsEventWidget + Slow Mercurial Log

[Fabian Wiesel]

On 15/01/10 16:00, Andreas Pakulat wrote:
> 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.
>    
True git poses a small problem. One could realise an enumeration
of hashes via git-rev-list, but then  one wouldn't have the most general 
interface.

Otherwise, for SVN and Hg it depends on what you understand as knowing.
I, as a user of,  IBasicVersionControl don't have to know the whole history.
I can do the equivalent of:

svn log -r 0:HEAD --limit 1
 > r90377 | hoelzer | 2001-04-04 18:46:51 +0200 (Wed, 04 Apr 2001) | 2 lines

But I have to say, it seems as slow as running through the whole history.
I don't know, if it is faster via the API.
At least the equivalent for mercurial takes no time at all, but my 
repository
history is quite a bit smaller, and runs locally.

hg log -r 0:tip -l 1 .

Both give allow me to make an upper ceiling estimate about how many 
revision
there might be between 0:HEAD.

The user moves a slider to a position. I make a estimation about the 
requested revision
by linear interpolation. I request a number of revisions around that
estimated revision number, the returned revision allow me to re-estimate
the position-revision number relationship.
Practically a binary search.

It slipped my mind, that git doesn't have a sequential numbering at all.
So this probably is a bit over the top. However git can provide a
sequential ordering, see git rev-list.

So one could realise the above in a "light" version.

Let say the dialogue provides space for X revisions, fetch the first X and
leave space for 3*X more. If the user moves into the next X block, fetch it
and add another "virtual" block. If the user moves to the last X block,
fetch it. Add a virtual block above it, to let the user scroll backwards.
Fetching the bottom will take how long it will take. In case of git and hg
fast, in SVN the same as before, provided there isn't a faster path in 
the API.
Of course, the sizes of the blocks don't have to be the same. The final 
block could
be a single line, to avoid, that the user will request the last block by 
accident.

Fabian