Karsten Blees wrote:
> Am 11.02.2013 04:53, schrieb Duy Nguyen:
>> On Sun, Feb 10, 2013 at 11:58 PM, Erik Faye-Lund <[email protected]> wrote:
>>> Karsten Blees has done something similar-ish on Windows, and he posted
>>> the results here:
>>>
>>> https://groups.google.com/forum/#!topic/msysgit/fL_jykUmUNE/discussion
>>>
>
> The new hashtable implementation in fscache [1] supports O(1) removal and has
> no mingw dependencies - might come in handy for anyone trying to implement an
> inotify daemon.
>
> [1] https://github.com/kblees/git/commit/f7eb85c2
Thanks! I'm cherry-picking this. Why didn't you propose replacing
hash.{c,h} with this in git.git though?
>>> I also seem to remember he doing a ReadDirectoryChangesW version, but
>>> I don't remember what happened with that.
>>
>> Thanks. I came across that but did not remember. For one thing, we
>> know the inotify alternative for Windows: ReadDirectoryChangesW.
>>
>
> I dropped ReadDirectoryChangesW because maintaining a 'live' file system
> cache became more and more complicated. For example, according to MSDN docs,
> ReadDirectoryChangesW *may* report short DOS 8.3 names (i.e. "PROGRA~1"
> instead of "Program Files"), so a correct and fast cache implementation would
> have to be indexed by long *and* short names...
>
> Another problem was that the 'live' cache had quite negative performance
> impact on mutating git commands (checkout, reset...). An inotify daemon
> running as a background process (not in-process as fscache) will probably
> affect everyone that modifies the working copy, e.g. running 'make' or the
> test-suite. This should be considered in the design.
Yes, an external daemon would report creation of *.o files, from the
compile, for instance. We need a way for it to be filtered at the
daemon itself, so git isn't burdened with the filtering.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
