How to Iteratively Delete .svn Directories: A Better Way

By now, gentle readers, you have probably seen the Javamancy mini post about the one-liner deletion for .svn files.

I really like Adam Bien. He seems like a nice guy, and I occasionally drop by his blog, on a lark, to read his stuff, which is often focused on Java and NetBeans, one of our favorite IDE’s that we use regularly for DevPal and Javamancy dev work, especially for Java and PHP. Now, I have never met him personally (which is unfortunate, since the inevitable Formidable Brain-Pick would come out, and I’d be picking his brain with it furiously (figuratively, ‘natch)), nor have I observed his programming, CM, and shell skills in action.

So I thought it was curious that he posted about how to delete all .svn files with a “one-liner”. Being a collector of snazzy UNIX scripting that make my life easier, I just had to look…

The Debated Script

Now, keep in mind that Adam mentions that he found the one-liner elsewhere, but he liked it enough to post it.

Here is what he suggests as the one-liner:

find . -name ".svn" -exec rm -rf {} \;

And this would be fine, under normal circumstances, if you are considering a relatively small population of .svn files that you want to remove and you do not care if somebody mistakenly named something on the filesystem as “.svn” despite it not being a Subversion directory.

But if you are like me, and/or you have at least one of several different CM structures that you support within one or more different versioning systems, and/or you have both people and automata that frequently access and modify those CM structures, you are most likely going to have thousands, tens of thousands, hundreds of thousands, or perhaps millions of .svn directories that you have to account for. And you may have noticed that when you feed a large parameterized file list to the rm command directly causes it to choke after only a few hundred (or in some cases, several thousands, depending on your OS) entries.

What DevPal Does

So here’s an excerpt from one of my scripts that leverages the xargs utility to spoon-feed the rm command with smaller digestible chunks from the potentially huge file list that the find command readily retrieves:

find . -type d -name .svn | xargs rm -rfv

Like Adam’s snippet, I want to use the current directory position, but if you want to parameterize that to some other location (i.e., other than “.”), you certainly could.

Also, note that I’m only interested in directory names… I am not interested in non-directories that match “.svn“. This may or may not be the behavior you are supporting, so you may want to change the filetype specifier (say, to “f“) or drop it altogether.

Now, for the rm command switches: I tend to like to see what is going on during the deletion process, so in addition to inducing recursion through directories and forcing deletion without confirmation, I also want a bit of on-screen verbosity to show me what is being deleted. In this way, if I want to log the behavior, I can certainly redirect the output to a file or to a remote service. Anybody Hudson’ing, or just Ant’ing or Maven’ing with this?

Script or Not?

Technically, while Adam offered up the one-liner as just that… a one-liner… I would guess that many of you have wondered about whether it makes more sense to wrap a script around it and give it a snazzy name. My recommendation is, of course, yes.

N.B.

.svn as a directory

You may have noticed that there seems to be an interchangeable use of “files” and “directories” when referring to the .svn content. Which is correct? Both, actually, and it depends on your approach or perspective.

Contents of the .svn directory

Whenever you browse your local directories within your sandbox, you will see that the .svn entries are actually directories. But if you peek into those directories, you will notice that there appears to be a set naming scheme to the files in there… as if they are arranged in a certain way to allow something (like a local database engine or parser ( )) to efficiently access and modify the metadata for the versioned content. So, when referring to the .svn structure and contents, the UNIX-y notion of directories being also files can be more-inclusive.

By the way, this notion is also applicable for other versioning systems, including CVS (Subversion’s forebear).

Tagged as: Adam Bien, configuration management, Java, Javamancy, Javamancy mini, Linux, NetBeans, OS X, PHP, UNIX