How to grep without hitting Subversion’s text-base files

It doesn’t take many tools to program. At least it doesn’t feel like it takes that many. Obviously a computer. A lot of people are using Macs nowadays. What better reason to start using Ubuntu on a PC.

At Federated Media I’m finally using source code control, in our case Subversion. I had been doing isolated CVS commits on my own code at O’Reilly, but now that I’m working on a codebase with three other people, I have to say it actually makes working together exciting.

So my work is all svn st, svn diff, svn up, and svn commit. I’m editing text in gedit. No IDE, plain old vanilla gedit seems good enough. I’ve tried Emacs, Bluefish, gPHPEdit, EditPlus under Wine. But always back to gedit after few days.

I find myself doing a fair amount of refactoring, across lots of files I’m not familar with (though getting moreso), and when I make a change I want to be fairly confident that I won’t break a dependency I didn’t know existed. Enter grep. Other than forgetting whether the search pattern or the file argument comes first, I’m pretty handy with grep. grep -r sometext * was my new best friend…

…until I discovered something really really annoying. Since I was using it across many directories resursively, not only would grep return the files I wanted it to, it also returned Subversion’s cached copies of the files in the hidden .svn directories. Yuck! What a mess, grep would return useful results, but I’d still have to pick through them skipping over the .svn/… results.

I googled every possible phrase I could think of that meant how do I prevent grep from returning subversion files, figuring this would be FAQ #1 for anyone writing code under Subversion. No dice. Finally after some extreme phrasal gymnastics, I found a session description for a presentation at an upcoming KDE conference in Ireland that closed with this tantalizing nugget:

And other tricks like grepping without hitting subversion’s own copy of the files

Time to gather information the old-fashioned way: by asking a person. So last month I sent an email to the session presenter, David Faure, and he told me he uses wcgrep, a bash script from the Subversion sources (not installed by default) that’s worth its filesize in gold.

I dropped it into /usr/bin, and now I wcgrep sometext with wild abandon (as an added benefit, the -r recursive option and trailing asterisk are optional). And occasionally when I just want a list of files that contain some method name, I whip out wcgrep -l sometext. And that’s pretty much what I do all day.

Many thanks to David Faure for pointing me in the right direction and Ben Reser for writing wcgrep.

Feel free to if you found this useful.



I have also found that using find and grep together are quite useful:

find -type f -name "*.[ch]" -exec grep {} \; -print

But man, find, while powerful, has the least memorizable syntax. Good for aliasing I guess.

I often found myself piping the results to some file grep -r 'wtf' * > file then opening that file in vim and regex-ing out the lines with .svn. This seems handier.

Instantaneous feedback is definitely handier.


Thanks! I sorely needed this…

The following seems to work well enough for me, though I still get occasional false positives. Maybe someone can explain why and post an improved version:

fgrep -R --exclude='*.svn*' -I searchText *

-R = recurse subdirectories with extra operands (in this case, exclude filenames containing .svn)

-I = ignore binary files (my class files)
searchText = the search text


Email (optional)

Blog (optional)