On Mon, Mar 10, 2014 at 12:42 PM, Dennis Luehring <dl.so...@gmx.net> wrote:
> Am 10.03.2014 12:28, schrieb demerphq:
>> I had the impression, and I would not be surprised if they had the
>> impression that the git development community is relatively
>> unconcerned about performance issues on larger repositories.
> so the question is if the git community is interested in beeing competive in
> such large scale scenarios - something what mercurial seems to be now out
> of the box
AFAIK, David Lang's comment is not far off the mark. Facebook has made
a tool called Watchman (https://github.com/facebook/watchman) that
watches your work tree (i.e. wrapping inotify on Linux) and triggers
various commands when files within are changed (e.g. do an auto-build
whenever a file in your project changes). Since this tool will
discover when files change, they have adjusted Mercurial to discover
changes by querying Watchman instead of stat-ing the entire work tree.
AFAICS, this is basically a tradeoff between the time it takes to stat
your work tree and the overhead/administrivia of running a daemon to
monitor the work tree. It seems Facebook has organized their code and
infrastructure in a way that makes the latter approach worthwhile for
them, and has contributed their solution back to Mercurial.
It should be possible to teach Git to do similar things, and IINM
there are (and have previously been) several attempts to do similar
things in Git, e.g.:
I haven't looked closely at these attempts (it is not my scratch to
itch), and I don't know if/how they would work on top of Watchman, but
in principle I don't see why Git shouldn't be able to leverage
Watchman the same way Mercurial does.
Johan Herland, <jo...@herland.net>
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