Do you ever spend a vast amount of time searching the web for how to do something that you know ought to be trivial, something you know takes 30 seconds to do, and will save you a huge amount of time, if only you could find out how to make it happen?
Even worse, you know that given sufficient time, you could probably dig it out of the man pages or documentation, but “sufficient time” is invariably open-ended, meaning “spend as much time as required.”
Might take 2 minutes, 2 hours… or 2 days!
From a command line perspective, you can think of these as “incantations,” magical phrases that are very short, yet very powerful. For example (i.e., instructional purposes only), # rm -rf . will destroy everything, permanently, in whatever directory it’s invoked. Even in root. Short. Powerful.
Not FAQs are not-FAQs
I hate chasing down such incantations. Invariably, I end up on the chase because asking on a forum too often results in “RTFM.” I have a whole article forthcoming on why “RTFM” is a dumb answer (hint: wastes everyone’s time), and besides, man pages aren’t always very readable. What I’m looking for isn’t a FAQ…
…it’s a not-FAQ!
not-FAQs are intelligent questions requiring simple, powerful answers. Incantations, answers that are meaningless to the typical asker of a FAQ. The following not-FAQ requires a fair bit of knowledge of version control systems.
Once, I spent hours and hours chasing down a not-FAQ: searching for a fast way to specify files for Subversion to ignore. I had accidentally added and committed some working files that are irrelevant for source code revision purposes. I had been using CVS for years, and ignoring files in CVS is simple: add them to the .cvsignore file, add the .cvsignore file to the CVS repository. It doesn’t work the same way in Subversion, and the experimenting I was doing using the man pages (links below) weren’t working.
So, for whatever reason, I was thrashing on how to do this really simple task in Subversion. I found the SVN book (links below), which told me everything I didn’t need to know at the moment. This is the usual problem with “complete” documentation: most of it is irrelevant to the casual user, where the Pareto Principle applies. I was overwhelmed with documentation!
In any case, I finally asked a colleague, and he provided the following.
>>NOTE: You can dig this information out of the official Subversion book, but it might take you quite a bit of experimentation to get the exact procedure figured out. Go read the book after you play around with the technique here… the book will then make much more sense*
Specifying svn:ignore property
Here’s the fast way to specify directory-level patterns for ignoring certain files when using Subversion, that I got from Andrew Mustun, the proprietor of Ribbonsoft GmbH and author of the excellent QCAD application:
- The first thing is to tell Subversion how to edit files in general. I use vi because it’s fast, efficient and present on every unix and unix-like operating system in the world. (Actually, I just like vi.) Here’s the command for setting the Subversion editor property:
$ export SVN_EDITOR=/usr/bin/vi - The next step gets to work, using Subversion to track the editing:
$ svn propedit svn:ignore . - Commit your changes and you’re done:
$ svn commit -m"Added list of file patterns to ignore."
Smart bears will put that in their .bash_profile, and never have to think about again.
Add file patterns such as “*~” or “*.bak” one per line. ESC then Shift-ZZ and you’re done.
Here’s a screen shot of what editing propedit svn:ignore in cygwin bash looks like (click on image to get higher resolution file):
Editing svn:ignore property from cygwin bash prompt.
