At Startup Weekend Seattle this past weekend, the team used Subversion for its source control needs.  It’s a robust, stable, and usable product.  I have zero complaints with it whatsoever – in isolation.

But today I’ve been wondering if the CVS/SVN locking model maybe is bad from a Continuous Integration perspective.  Here’s the scenario I’m thinking of:

Andy makes changes to two files:

• lib_component.cs
• frontend1.cs

Where the change to frontend1.cs depends on the changes to lib_component.cs.  Andy commits and everything is fine.

Then, Bobby makes changes to two files:

• lib_component.cs  // same file Andy just changed
• frontend2.cs

Again, Bobby’s front-end changes depend on the simultaneous change to lib_component.cs.

If SVN can’t resolve Bobby’s edit to the library component, then the CI build that follows Bobby’s checkin is going to fail.  Now, you could argue that it’s Bobby’s fault for not making sure to work from the latest version of lib_component.cs, but in a fast environment, with commits happening fast and furious, it may happen.

I suppose it depends on what percentage of times you’ll get stuck with a merge that Subversion can’t handle automatically.  In practice, this might be a low number.

My gut tells me that if we had CI up and running at Startup Weekend Seattle, it would have been sending broken build notification errors more often than it would have been sending success messages.

Am I way off base here with my thinking?

Over the past two or three years, I’ve tried — really tried — to love CruiseControl.NET. It’s a great idea to help people like me who need good SCM tools to do our job. Unfortunately, CCNET has two major, glaring problems:

1. It’s unfriendly as hell to configure and use.
2. It doesn’t get updated more than once a blue moon.

It’s that second point that has me thinking about open source vis-a-vis strategic planning (hey, even solopreneurs have strategic plans!). CCNET has been updated twice in 2007, most recently in June, and that release didn’t even address the main issue (point #1). Draco.NET, another continuous integration product that I use (and like), was last updated in January 2006. FIT, a third tool that I haven’t used but which seems like a great idea, looks like it hasn’t been updated to any large degree since April 2005.

How is it possible to scramble, be agile, adapt to new tools, new processes, new best practices, if you are relying on tools that are old and unsupported? Most of the developers, who are volunteers, have moved on to other, sexier projects, got married, had kids, whatever. Now you either (a) use what they left you back in 2005 or (b) move on to a new product, abandoning your investment (in time, not dollars, but which is more valuable for the young business? Hard to say).

The way I *think* these things should work is for the good projects to move to a paid model, a la Jamie Cansdale’s TestDriven.NET. This was a free product for a long while, started by a (very talented) hobbyist, which then turned into a reasonably-priced for-profit product. I was happy to pay the $100 or whatever it was to buy a copy, because the advantages are well worth it. In the meantime, Jamie continues to work on the product, Microsoft notwithstanding, and I have every confidence that this won’t become a “dead” product anytime soon.  Last update: two months ago.

I have no idea if Jamie makes a living off of TestDriven.NET or not. I hope so, but the point is that profit tends to keep the legs under a product in ways that are different from the open-source ethos, and it’s important to take that into consideration.