[PATCH 0 of 3] patches for TortoiseHg overlay icons

[Matt Mackall]

On Wed, May 20, 2009 at 08:54:35PM +0200, Adrian Buehlmann wrote:
> 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).

That's actually not an unreasonable approach. It means you can
absolutely minimize your explorer extension, probably maximize
performance, and keep most of it written in Python and directly using
the Mercurial API. It's also a good stepping-stone to something
inotify-like.

I really don't like the 1s thing. It can bite us on very simple
operations that should take < .1s. Putting it in is a step away from
solving the problem correctly.

-- 
Mathematics is the supreme nostalgia of our time.