proof of concept : hggrep

[mgix at mgix.com]

hg, like most other SCM tools essentially maintains a database
of changes, and it's always struck me how poor the query tools
for that type of db were compared to general purpose databases.

I typically use an SCM systems to try ideas. In the process, I
add code, change it, remove it, bring it back, remove it again,
chop it up and graft the pieces here and there. Every step of the
way I do commits, especially when I have something that works.

When you do high frequency commits, you don't spend much time
detailing what you did in the commit log, first because it's far
too time-consuming, and second because somewhere there is the
unshakable feeling that whatever comment you're adding to the log
is redundant since all the changes are tracked by the SCM in the
first place.

As I mentionned in my previous message, hg annotate is a great help,
but sorely lacks when the time comes to "resurrect" an old piece of
code because you realize twenty revision down that it actually was the
right thing to do : finding the rev where the code disappeared turns out
to be quite a pain.

To deal with the problem, I'm using a small perl script that helps
me quite a lot. It's very slow and would probably be orders of magnitude
faster if built directly in python into mercurial, but you can look at it
as a proof of concept.

You can get hggrep here: http://www.mgix.com/hggrep

Here's an example of its use: go to a recent hg repo and launch:

           hggrep -v HGTMP hgeditor

I haven't gotten around to coding the -p (search patches) option yet.

I'm trying to expand on this idea of "querying the patch db" and
come up with something that lets me find a specific change fast.
Any feedback an/or ideas are welcome.