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?









