In a previous article, part 1 of the series, I went through a few of the reasons you might want to consider using source control in your development infrastructure. I’d like to continue on that article with what I promised, some concrete ideas of source control systems you can consider implementing. I hope to highlight some of the major advantages and drawbacks of each system as well as give some context to help you make your decisions.
Here are the major players in the open source world:
- Subversion – This is the successor to one of the most popular open source revision control systems, CVS(Concurrent Versioning System). The developers of Subversion kept all of the good ideas that CVS had and removed the drawbacks. It’s been around since 2000, and still being actively maintained and updated. Major features are:
- Central repository – All your code is stored in one location
- Atomic Commits – If you commit multiple files, either they all go or they all fail. It’s not possible to have 5 out of 10 files commit to the system.
- Commit based revision system – Each commit increments the revision number, as opposed to one version number per file committed.
- Storage of file deltas – The source control system stores only the difference between files, rather than an entire new version of each file. This saves disk space. It also makes tagging and branching very cheap.
- Git/Mercurial – These could rightly be considered the successors to SVN. Git was created by Linus Torvalds, but is now maintained by others. Mercurial was the successor to BitKeeper, and both projects were started about the same time. While they are different products, I group them here because of their similarities.
- Distributed – Both of these source control systems throw out the notion that everything needs to be stored on one central server, like Subversion. The idea here is that there is a “Master” copy of the repository somewhere. However, should the Master copy fail for some reason, any others that have a copy of the filesystem can become the master copy. This is supposed to improve fault tolerance.
- Faster – SVN can occasionally take some time to do operations when revision history gets long. However, both Mercurial and Git scale better with larger codebases.
- Team Foundation Server – This is a Microsoft product that took a lot of the negatives associated with VSS (Visual Source Safe) and rewrote them in a better way. Microsoft added many of the ideas of the open source community, such as atomic commits, real branching and merging, and labeling (tagging).
Here are minor players that their zealots will swear by. I won’t take the space to do a full writeup. However, I’ve added links here in case you want to do your own research.
Here are revision control systems that you should strongly consider replacing as their drawbacks can be very costly.
- VSS – Microsoft’s first entry into the source control world. It’s disadvantages are checkout/checkin systems, no real branching, and the fact that your repository has a high percentage chance of becoming corrupt after it passes 2GB in size.
- CVS – Again, latest source control systems are 2 generations beyond this one. The longer you wait to make a change, the more painful the change will be.
- IBM Rational Clearcase – Ok, I have a personal vendetta against this one. It is difficult to use, has no real plugin for modern IDEs, doesn’t work half the time, requiring you to redo work, and you can’t recursively add files to the system (seriously?). I guess that’s enterprise software for you….
So, which one should you choose? As always, the answer depends. Here are some sample scenarios that you might look at.
- You don’t currently have a source control system, and your development staff is pretty inexperienced. You also need complete control. Your choice is Subversion. You manage the server, and it has one of the easiest learning curves out of all of them. There are numerous plugins for IDEs and you can pretty much use any development language you want.
- If you have a rock star development team that is already pretty familiar with revision control, you can get a ton of mileage out of Git or Mercurial. While I still believe your master copy should reside on a server, it doesn’t have to. Your rock star developers will appreciate not being held back by their development environment.
- You run a Microsoft shop and are heavily invested in MS technologies. You don’t mind paying for a good software product and want something that can integrate both development and deployment. Here, your choice is Team Foundation Server. Used correctly, it can significantly speed things up for you.
These are of course some very basic scenarios and hopefully they give you just a starting point for your research. As a manager, you need to balance features, cost, ease of setup and use, and your ROI. Be careful with anything you get from the sales staff of commercial products and try to do some research on what actual users of the products say. There are many blogs with comparisons of different source control systems out there. Above all, if you have rock star developers, trust their recommendation.
Lastly, there are some alternatives to running your own server. There are cloud-based instances of almost every source control product if you look hard enough. Two quick examples that come to mind (full disclosure, I have used neither of these products and cannot recommend or caution against) are Github, for open source projects and Bitbucket.