Re: New module proposal: tracker

On 18/08/09 16:57, Jamie McCracken wrote:
On Tue, 2009-08-18 at 16:44 +0100, Martyn Russell wrote:
On 18/08/09 16:07, Lennart Poettering wrote:
On Tue, 18.08.09 13:05, Martyn Russell (martyn lanedo com) wrote:
Hmm. The beef I have with Tracker (and Beagle fwiw) is that they build
something on infrastructure that currently is not good enough
to sustain it: inotify. inotify is simply not suitable for recursively
watching $HOME, but Tracker tries that nonetheless. And that is a big
big failure, it should not do that.

I agree the situation isn't perfect, but it isn't a BIG failure.

Currently Red Hat's Eric Paris is working on this with fanotify:

There are more links from Google of course.

There's something I like to call the "tracker paradox": if you have
a large data set tracker is useless because inotify doesn't scale and
the database is quickly out-of-date -- and if you have a small data
set then you don't need a search engine and hence tracker is useless

Well, that really depends on the user and the data set. Most "normal"
users don't have 10 versions of the linux kernel checked out causing
these inotify limits to be reached. With ALL my music and external
drives I don't have a problem with the limit at all. It seems that only
people with the whole of GNOME checked out into $HOME seem to run into
these cases.

Ideally this could be solved by the file miner checking to see if a
directory contains a hidden .svn or .git folder that houses a repository
and automatically skip that folder sub tree

We already do that. But some projects have a LOT of directories ;)

Most devs will use grep rather than tracker for searching source files
anyhow and I have never come across a situation where indexing soure
repositories is useful (there may be corner cases of course)

Precisely, that's why this case is so remote in the first place.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]