Re: New module proposal: tracker

[Jamie McCracken <jamie mccrack googlemail com>]

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:
> 
>    https://fedoraproject.org/wiki/Features/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
> > too.
> 
> 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

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)

jamie