Karsten Blees wrote:
> Am 11.02.2013 04:53, schrieb Duy Nguyen:
>> On Sun, Feb 10, 2013 at 11:58 PM, Erik Faye-Lund <kusmab...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to