sam griffith wrote: > Everyone, > > I've been playing around with opengrok while waiting for the release, > and was wondering if there was any way to configure it so that > multiple source directories were indexed, rather than one.
The concept of projects works this way. Under SRC_ROOT everything is a "project" Project has a separate index and with current trunk dev version you can search multiple projects at once. With Solaris ZFS(tm) you can easily mount datasets per project and opengrok fully supports such mounts and searches them (rather than symlinks). Above has only one problem and that is , that this works only for one level depth of directories. > > I see how to do it for one directory (or setting up mirroring) but in > my environment things are relatively fragmented (ie: source in > multiple areas), and I'd rather have one master opengrok database than > several small, disjoint ones. Disjoint ? Please tell us a use case to show why this is a problem(multi project search is in dev trunk and works nicely afaik and having more index dbs only gets you rid of one point of failure ;) ). > > So is there a way to have opengrok work with multiple directories, and > more importantly, do filtering to avoid files that are either > temporary or ignorable, and to do this via configuration? only using -i as Bruce suggested in OpenGrok script this is achieved using variable IGNORE_PATTERNS We try to target OpenGrok to be able to index any kind of file, so if there is a problem with some file, we'd like to know about it! If I compare 0.7 - I was able to remove all my problematic files from -i that failed in 0.5 ... with 0.8 this will be even better. When there is a problem with a file, it will be most probably skipped and the problem is reported as warning message and appropriate stack trace. last week we tested OpenGrok on clone of src.opensolaris.org and I really liked it ... thanks for the feedback, if some other folks tried out development trunk recently we'd like to hear from them too! Lubos > > Either that, or better yet configure it so that opengrok goes by a > list of files to index (so that say a python script could do the heavy > lifting of figuring out what to index and opengrok could pick up on > that and use it)? > > thanks much, > > - sam > > sam griffith wrote: > > Upon release I will update the install and user page > (it's really only 2 steps at the moment to setup > opengrok ;) ) > > I hope the release should be out any moment > > > > thanks much lubos, I'll follow the roadmap page closely. > > >
