A scant couple of days ago, Subversion (the project) formally graduated from its incubation phase, becoming a full-fledged Apache project at subversion.apache.org. It seemed like almost yesterday that it had been accepted as a candidate by the Apache Software Foundation (ASF)… In fact, it was in late 2009 that the proposal to join the ASF had been filed, and just a few months later, it made its way toward acceptance.

For those of you who are unfamiliar with what Subversion is, it is an open source file-associated content versioning system. Many developers who are familiar with RCS, SCCS, and CVS have probably heard about Subversion (SVN) as the “next step” toward versioning “modernity” or “modernness”, especially for those who are transitioning from traditional code branching and merging toward changeset management techniques. For people participating in agile configuration management (CM) and coding initiatives, Subversion may have even been selected as the primary (or even, sole) versioning system.

For those of you approaching CM for the first time during this latest iteration of Web development (circa 2006 and onward), while you may be more familiar (and even using) distributed/disconnected/decentralized versioning systems like Mercurial (hg) or Git or even monotone, you also may have heard of Subversion as one of the last vestiges of centralized versioning systems that organizations that have moved onto the current system have used in the past.

For others, the folks who have been using commercial versioning products like StarTeam or ClearCase, you may be scratching your head and wondering what all the fuss is about.

And for those you who’ve been deep in the CM trenches for awhile, you’re probably thinking, “Yeah, it’s about time.”

There are benefits and disadvantages to the features that Subversion provides, and depending on your development requirements, it may be 100% the tool to use, or it may cover enough of the features that you need that it’ll do the trick, or it may be insufficient to match your needs. But it always seems to be on everybody’s short list for consideration, replacing the position that the venerable CVS once held.

For public repository access, Subversion is very popular because a couple of its access methods involve leveraging HTTP rather than a proprietary protocol. For that matter, you may find site hosting services offering Subversion as a way to manage versioned content for Web sites due to its support for WebDAV (however incomplete) as well as to support development codebases, big and small.

So, we’re tickled pink that Subversion has made its way to ASF as a full-fledged graduated project at this time. Kudos!

I’ve always wondered how some popular open source and GPL projects keep going. Many times, they seem to implode upon themselves, whether due to internal or external forces imposing their undue influences upon the work at hand. The good ones realize that they are imploding and take measures to stop it from happening… and sometimes, they manage to successfully execute an appropriate plan of action in time.

Here’s an interesting live example: WordPress.

Scenario: WordPress

Jane Wells posted yesterday about an anticipated change to how WordPress development will change to fit a model that should address their scope creep problems that have been hampering their releases, of late. She refers to project management as providing the answer for their woes with scope creep; yes, there’s additional verbiage in the post, but essentially, that is what she is primarily referring to. There is that additional component to the problem, in the form of release scheduling, which plays a part in the problem set.

At this point, some of you will be nodding sagely toward your display screens (LCD’s, iPhones, BlackBerry devices, et al.) and thinking, “Well, project management techniques would help manage what is going on, but… there’s something else in play that needs to be controlled, right?”

Management Perspective

Yes, sage thought (or thinking sagely, perhaps?), indeed.

While project management in general is a useful discipline or tool to have, even for small teams, especially those that conform to a matrixed (or “mixmaster”) configuration, it is not the magic bullet that many people think it is.

In essence, it is a way to react to chaos in the workplace by arbitrarily grouping workstreams into some semblance of order, based on a variety of criteria, like limited resource availability, priorities, scheduling conflicts, release dates, et al.

However:

What if trying to rope in the insanity of scope creep and meandering requirements are symptoms of a greater problem? Using reactive techniques to mitigate further damage to a production schedule is only an immediate-term fix.

Instead, determining a new way to manage requirements intake and development, and a new workflow cycle for controlling change and releases, would be much closer to a longer-term solution. Figuring out the most appropriate mechanism by which to introduce and control change (whether fixes, new features, extensions, etc.) and to align them with ongoing development and documentation is the basis for the transition toward a fully-realized workflow that integrates configuration management with project management. Of course, not an easy task (certainly, easier to simply state what seems to be needed for this scenario, as opposed to actually implementing it)… But a lot of the basic tools to build upon are already in-place or being used or available.

So, this will be an interesting live scenario to follow.

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).

Well, as I was mulling over the WordPress 2.8.1 code progressing its way through DevPal’s CM automata (yes, Javamancy really IS part of DevPal), I noticed that there was an entry from the WordPress guys (more specifically, Ryan) on their WordPress 2.8.1 release drop, which was officially back on July 9, 2009.

For even more reading fun, here’s the link to the Trac list of issues addressed by the release.

Go figure, folks.

The Setup

“What should you do when that Ol’ Tester Magic grabs a hold of you?”

Dunno.

But what you can do is sit around at a nearby coffeehouse, drink your coffee, finish your coffee, get a refill and drink that one, and then declare to all the other crazies sitting around you that you’re going to set up a bunch of publicly accessible test/preview sites.

The Premise

We’ve been doing plenty of testing internally for a variety of stock and commissioned software products and components, which is all great and fine… at least on the Java side. It’s a fairly well-understood, documented, regimented series of cooperating workflows that mesh well.

But what about the PHP code that we’ve been trickling out into the public? Or Web sites, like Javamancy, that have a structural aspect alongside the content (such as this post) that require careful feeding and maintenance over its lifetime? Don’t they also deserve a more extensive set of tests, previews, new concepts and integrations, etc.?

The short answer is: yes.

The Action

The plan is simple: starting soon (ostensibly in April 2009 if we stick to the initial development schedule), we’ll be setting up a few test/preview sites for Javamancy, among others, so that our kind and gentle readers will have an opportunity to see new features as they enter our pipeline for the public-facing (and some commissioned) Web-based products. These activities should not significantly alter many of your current work habits (at least, hopefully not), and it should not deter our Java folks from continuing with their favorite products and services that they know and love.

Just think of this as something “extra”.

Because when that Ol’ Tester Magic grabs a hold of you, odd things seem to happen…