2012-05-08 13:03 AEST by Arthur Barrett - it would be great to be able to search the repository from the cvsnt client

There are lots of diffierent search possibilities, eg:
* lexical search (all the files/revisions which use GetCustomer(), or override NewCustomer()
* text search (find the most recent revision of blah.c that contains the string "this is a bug)
* binary search (find in word documents)


This is easier to do in EVS than CVSNT, but if we are incorporating an SQLite database, then all sorts of 
things are possible...

We previously offered this sort of thing using lxr from mozilla (now called mxr) and glimpse:
http://mxr.mozilla.org/
and
http://sourceforge.net/projects/lxr/
and
http://webglimpse.net/

This is also discussed in bug6084 under spotlight integration.  I still like the idea that the host OS of the 
server could provide the engine for this rather than CVSNT itself.

Maybe Windows Search 4 - iFilter interface would be good enough...
http://msdn.microsoft.com/en-us/library/windows/desktop/dd940336(v=vs.85).aspx

2012-05-08 13:40 AEST by Arthur Barrett - There is a free Java-based full text search engine "Lucence" also used by Eclipse and Jira is this:
	http://lucene.apache.org/core/

There also seem to be Lucene ports to other languages:
	http://wiki.apache.org/lucene-java/LuceneImplementations

E.g. one for C++:
	http://sourceforge.net/projects/clucene/

2012-06-20 10:14 AEST by Arthur Barrett - DXR has been popping up in my search results recently:
https://wiki.mozilla.org/DXR

eg:
http://zenit.senecac.on.ca/wiki/dxr/source.cgi/mozilla/toolkit/crashreporter/google-
breakpad/src/client/mac/handler/minidump_generator.cc

2013-04-02 13:53 AEST by Arthur Barrett - There probably needs to be three parts to this:
- command line interface, 'cvs search' or 'cvs grep' or 'cvs find'  
   this could be based on 'cvs log' and there could be 'cvs rfind' like rlog
- WM GUI interface
- Web Interface/Server Side interface

The server probably also needs to distinguish between searchable and non-
searchable files.  eg: a .doc is searchable but binary, and a .sln file is 
(probably) not searchable but text.  This should *NOT* be a keyword attribute, 
but something more 'dynamic' so that files/revisions can be labelled for search 
one week, but then removed from searches later (or vice-versa).

There is already a GREP library linked into the 'core' - so at a 'minimum' this 
could be a simple grep search of the RCS files.  It wouldn't give 'revision 
level' searches, but it would be 'something'.

2013-04-02 23:59 AEST by Glen Starrett - Just brainstorming here:  It would probably be useful to distinguish  "metadata"
from "contents", and "on branch" vs "anywhere".

E.g. Search for specific contents on branch X, or search through comments.

2013-04-03 12:12 AEST by Arthur Barrett - 
search options should include:
-w				dumb search everything/whole RCS file
-p				search 'user' properties
-c				search comments/log
-t				search 'text' (ie: contents)
-r[revisions]		search revision/range/branch - same -r syntax as log/rlog
-d dates			specify dates - same -d syntax as log/rlog 
-T				Use local time not GMT.
-w[logins]			Only search revisions checked in by specified logins.
-g				grep search
-e				egrep search
-l				lexical/keyword search
-ox				output xml
-ol				output just the names of files
-oe				output the extended search result

The first implementation (or the easiest to 'quickly' implement without the need for lexical analysis or any 
extra 'database' would be the 'whole RCS file' option: -w