[PATCH 0 of 3] patches for TortoiseHg overlay icons

[Adrian Buehlmann]

On 20.05.2009 20:17, Matt Mackall wrote:
> On Wed, May 20, 2009 at 08:07:26PM +0200, Adrian Buehlmann wrote:
>> These changes would enable TortoiseHg to update
>> the overlay icons on Windows explorer (the Windows "Desktop").
>> Folks are very keen on having those icons. Now it would
>> be possible to have them at an acceptable speed, even
>> for large repos with number of files in the >10K range.
>> We are currently directly reading .hg/dirstate
>> with a dll that is loaded by explorer (a so called
>> shell extension, written in C++, complied with MingW --
>> design idea taken from CuteHg project).
>>
>> The patch series makes sure, that we have no 'unset' entries
>> in .hg/dirstate (see 'hg debugstate' after e.g. clone) when
>> Mercurial finishes, and provides a new hook that is called
>> _after_ .hg/dirstate has been updated by Mercurial.
> 
> Can't say I'm excited about this approach. Why not simply call hg st <entries>
> after unset entries are encountered to fix them up?

Yeah, this is what I feared (mpm not excited :)

I'm not excited about an additional 1s delay as well, but
the root evil is explorer.

I have been thinking about firing up a process
that would 'hg st' the unset entries, yes
(we don't want to indirectly load python.dll any more into
the address space of explorer.exe -- and thus other
applications as well -- so we don't want to call Mercurial
directly from within the shell extension any more).

But that would happen immediately anyway after
touching the working tree and this would lead to
fire up the icon updating at least twice for one
touch in the working tree. This whole thing might
even eat up more resources than the little 1s delay in
the first invocation of hg. The bzr Tortoise even
when so far as providing a bzr 'server like process' for
such things (I don't like that either).

I was also wary of doing it, as we would then have to
notify explorer.exe when done, that it must query the
file status on the explorer extension again (MS even
provides an API for triggering that), which might in
turn lead to calling that hg st process again if
there is anything broken with it (endless loop in
explorer: reset switch to the rescue, yikes!).

I currently see the 1s speed penalty as the far
lesser evil. And it would be off by default anyway
for the non-TortoiseHg Windows install.

TortoiseHg has been making a bad impression for quite a long
time now on Windows with the default-enabled horrible
speed of the overlay icons and the dll-version hell (python.dll
hell loaded in to explorer.exe _and_ applications that fire
the "open file" dialog!).