Our recent post on Source Code Control led many to ask, what does Backblaze use? The short answer is Subversion (SVN). The longer questions are: why did we pick it, how has it worked out, and should we switch?
What Most Companies Use for Version Control
According to the folks at Duck Software Open Hub (formerly Ohloh.net), Backblaze is not alone in using SVN; in fact, SVN is still the most popular repository among the registered Open Hub users as you can see in the chart below:
Why SVN for Backblaze?
Backblaze has used SVN since we started in 2007. It was selected and set up by Brian Wilson, our CTO. On his personal blog, Brian, documented his experience in getting SVN up and running for Backblaze. Some of the article specifics are a bit outdated as the server used was running Windows Server 2003, but the overall process still works. As a side note, the Dell Optiplex server Brian used was only recently retired from service.
Brian chose SVN for Backblaze even though he had not used SVN before. Previously he had worked with Perforce and CVS. Using Perforce was out because we would have to pay for the licenses and when you are bootstrapping a company from your own pocket, such things are luxuries. He asked around and several of his friends suggested SVN. In mid-2007, SVN was becoming well known in the developer community, while CVS seemed to be languishing. In hindsight, either choice probably would have worked for Backblaze, but Brian went with SVN and never looked back.
Brian installed and used SVN even though at the time he was the only engineer. Why? Rule #1 of Brian’s 10 rules for how to write cross-platform code, “Simultaneously develop—don’t port.” He would write code initially on his PC, check it into SVN, and then check it on his Mac to make sure it worked. This allowed him to quickly develop our cross-platform “base” libraries (Rule #5) that we continue to use today.
Our Experience Running Subversion
As Backblaze has grown since 2007, not only have we added more engineers to SVN, but we’ve also had more departments get on board. Today, our tree manages contributions from engineering, operations, web development, and even marketing. Subversion has been a good fit for Backblaze as we are fairly linear in our development practices. We rarely (if ever) branch our code, instead adding things in a continuous fashion. That’s not as crazy as it seems, as noted by Martin Fowler, a self-described champion of continuous integration:
“Subversion encourages a simple central repository model, discouraging large scale branching. In an environment that’s using Continuous Integration, which is how most of my friends like to work, that model fits reasonably well. As a result Subversion is a good choice for most environments.”
“If It Ain’t Broke…”
I polled some of the engineers at Backblaze to get their sense as to whether they’d consider changing from SVN. There was some enthusiasm for moving to GIT and a couple of votes for Mercurial, but the most prevalent sentiment was “if it ain’t broke, don’t fix it.” There was also a realization that at some point change could be inevitable as the team continued to grow in size and product continued to increase in scope, but right now the team can still “Grok” the system using SVN.
Would You Switch From Subversion?
On the Stack Exchange network there is a great discussion on why someone might consider changing from SVN and consider another system (mostly GIT or Mercurial in this case). The discussion is a couple of years old, but still worth reviewing. In addition, the discussion includes references to other resources worth reading, as well.
For the moment, Backblaze is sticking by SVN, but just for fun let’s make you the Backblaze CTO. As CTO, you are charged with looking into your crystal ball to determine what we should do over the next couple of years. Below are a handful of high-level requirements to get you started.
- The version control system should be open-source, but reasonably well supported by the community.
- We don’t branch very much today, not because it’s hard with SVN, but because we don’t need to branch very much.
- We have well defined teams for the Mac client, Windows client, server functions, operations, and mobile services. Code check-in conflicts do not occur very often and when they do they are mostly obvious and easy to solve.
- About 10% of our Engineering group lives and works out of state, visiting our headquarters in San Mateo once a month or so.
- We have non-engineers (i.e. marketing and operations) using SVN today.
Based on your experience, what other things should we be considering? What source code control system do you use? Why did you choose that one? Is it everything you thought it would be? We’d love to hear your thoughts.
