Source Control Paradigms and Continuous Integration

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?


2 Responses to “Source Control Paradigms and Continuous Integration”

  1. 1 Craig Huizenga January 30, 2008 at 9:15 pm

    Subversions commits are atomic, so if there is a problem with one of the files in the commit, none will be commited. Also, any merge issues would be taken care of before the commit, since if you try to commit when a file is out of state, it will cause the whole commit to fail, and tell you to update and merge your files first. Of course, if you don’t run you tests after you update and before you commit, you could very well find that the merge didn’t work very well, and break your code – but that’s your fault for being a dumb-ass (yes, said by someone that has done it several times…), not SVN’s.

  2. 2 Anthony Stevens January 30, 2008 at 10:20 pm

    Awesome. That makes sense. The CI product I use (Draco.NET) runs on what’s called a “check-in”, which I believe is equivalent to a SVN commit. So the CI build wouldn’t run until the merge problem was resolved.

    Question: will the SVN update command fail if there are merge problems? Or only the commit portion? Seems like it would be consistent with what you wrote if the update would fail as well.

    Thanks Craig!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

TwitterCounter for @anthonyrstevens
Add to Technorati Favorites

RSS Feed

View Anthony Stevens's profile on LinkedIn

%d bloggers like this: