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.
I have also found that using find and grep together are quite useful:
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…
[…] via […]
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