hgwatchman: inotify that works
martin at geisler.net
Tue Sep 3 01:57:43 CDT 2013
Siddharth Agarwal <sid0 at fb.com> writes:
> On 09/02/2013 01:09 PM, Martin Geisler wrote:
>> Siddharth Agarwal <sid0 at fb.com> writes:
>> That's really cool! Thanks for the hard work you guys are putting into
>> I tried it (after fixing some small 32-bit build errors in watchman)
> If you have time, patches for them would be appreciated. We don't have
> CI set up for 32-bit builds on any OS, so they invariably break.
My patches have already been sent and applied!
>> with the OpenOffice repo where there are 69k files in the working
>> copy. The repo is on a SSD and the time went from 0.5 sec to 0.17
> That sounds about right. I'd suspect the benefits of such an extension
> show up only once you hit 100-150k files or so.
Even with a "smal" repo like that, it's good to see the overhead of
querying the daemon is smaller than the speedup given.
>> For fun, I tried with the statdaemon extension I wrote a long time
>> ago. There I didn't see any performance improvement when I turned it
>> I haven't looked at watchman in detail, but do they do something like
>> I had to do here to make sure I get a consistent view of the
>> That is, touch a well-known file and wait until the event thus
>> generated is seen. Assuming that FS events are delivered in FIFO
>> order, the daemon knows that it has seen all events up to the time it
>> was called when it sees the touched file.
> Yes, that's basically what we do, though we use temporary files
> instead. See
Cool, that's basically the same idea, but without having a timestamp
file lying around. Do you know if this was discussed elsewhere than on
Have you looked into porting watchman to the Windows FS monitoring API?
More information about the Mercurial-devel