I’ve worked with a number of source code control systems and looked into most of the common ones at one time or another.

Those I’ve used for serious work:

• Visual SourceSafe

  VSS has gotten a lot of mileage as its per-seat cost is low (and zero with MSDN subs) and for small teams its capabilities are adequate. In a number of cases it was the source code control system that was in place when I started working with a team.

  Its performance is acceptable as long as all team members are (or can be via remoting) of the local high performance network. It uses direct file system access to manage its database and thus provides only very limited security. This has not been a huge problem as your in-house development team is trusted in any case. It would be a possible problem if outside developers needed access. Its scalability has been questioned in places, but to date I’ve seen pretty large repositories running without significant issues. Some obvious operations (branching and labeling) don’t work in the obvious way, but there are ways to accomplish everything that I’ve needed to do.

  At this point it is getting very old and creaky, but for a small local team that needed a quick and easy way to manage source code control I might still look at it as a readily available and well understood solution

• GIT

  I have been using GIT as my local source code sandbox repository for some time now. It is rugged, simple, easy to use for what I need and makes mirroring of work easy. When I’m heading home I can push my days changes to a flash drive and know that I’m in good shape to keep things going that evening if there is a need. The fact that it doesn’t use deltas makes it a bit more of a storage hog than most other choices, but given the size of storage devices and the extra robustness that comes from this choice I’m likely to stick with it for personal projects. The fact that it has supported huge, widely distributed open source projects on the net give me confidence that it will scale to meet pretty much any need.

  The biggest down-side I can see to GIT is the command line interface that is its default front end. I am comfortable with it at this point, but I’d be reluctant to try to introduce most development teams I’ve worked with to GIT as their default source code control system. I know that there are GUI wrappers for GIT, but the ones I’ve seen looked a bit limited (and half baked in some cases). There may be better options out there now as I haven’t gone looking in some time. The requirement that you pull the entire repository onto your local machine could be another issue in cases where the code base is very large. I could imagine that it would make sense to split things into multiple repositories in some cases to permit developers to work on subsets of the entire code-base though I’d imagine this would extract a price when dealing with branches and such.

• Old school zip or tar ball

In my first software job the group had no source code control system of any sort in place when I started and as I moved into a lead role I was aware that this was trouble. At the time the only packages I was at all familiar with were RCS and SCCS (and CMS from VMS but that clearly didn’t apply) and neither was a good choice for the small team at Howtek. I ended up instituting a simple system where code was handed to a central location (each engineer had a separate processor board that they were coding for so no merges) and periodically a version number would be assigned to the result and a zip file created containing the source tree at that point. I’d never go back to this as I know there are better alternatives, but it worked surprisingly well for the five or six person team we had.

• Perforce

  Perforce is a rather nice and rather expensive source code control system. It appears to scale well, support branch and merge operations as well as anything I’ve worked with and has an easy to use and easy to teach GUI. Aside from the ‘expensive’ aspect I’d be comfortable pitching Perforce to any place I’ve worked. It support change-lists (which is one of the limitations on VSS…it doesn’t) and seems to have a robust back end. I’ve seen it used to support six million lines of code without showing any stretch marks. If the team wasn’t comfortable with GIT and the team and project was large enough to demand something of this scope I’d be comfortable going there.

  One issue I have seen with teams that use source code control systems with very expensive per-seat licensing is that the pool of employees with any sort of access tends to get squeezed. I’d rather have engineers who have occasional need of access (read only or read write) get access as needed rather than having a small group of developers acting as gate keepers (and the associated lack of check-in traceability as checkins get delegated to those with active seats.

Those I’ve Investigated or played with

• CVS

  CVS seems to be pretty close to VSS in features and functions but with an open source implementation and somewhat fragile back-ends. It we the first open source source code control system that I looked at seriously as I was seeing VSS working well, but concerned that it was getting old and creaky (and not certain that Microsoft had a long term commitment).

  In the end I concluded that CVS offered little incentive to move from any other option, that there were better alternatives out there in open source and that the number of warnings about back-end fragility and corruption issues left me deeply uncomfortable about serious work with the tool.

• Subversion

  Subversion seems like the most credible option to CVS (and was explicitly created to be such an option). It appears to be more full featured and more robust. It seems to be functionally not that far from Perforce. I still have seen too many concerns about the back ends to be comfortable with it for things that matter (though I haven’t looked into the situation in several years as GIT has been working for me). The last time I looked at it, it appeared to be a decent solution, but not worth scrapping the existing system to make a transition.

• Team Foundation Server

  This is Microsoft’s heavy duty replacement for VSS in their line up. Most of the research on this was done by a coworker so what I have is the distillation of his investigations. It seems like a very powerful and highly integrated source code control solution. The back end appears to be into SQL Server with all of the power and reliability (and cost) that a full fledged databased server brings to the table. We were looking at budgeting for a deployment and getting this in place but with SMR being end of lifed this isn’t going to happen. I believe that it would have served our needs though probably a much heavier weight solution than a team with a half dozen developers needed.

• ClearCase

  I have been close to ClearCase implementations but never yet had to work in that environment. My impression from a close distance is that ClearCase is a poor solution for most modern needs. It appears to require aggressive and skilled support and presents a highly integrated and intrusive presence in the work flow. Having the source code control system present as a networked file system seems like unnecessary complexity for the job at hand and the costs of purchasing seats and hiring dedicated administrators makes this a complex and expensive option that might make sense for very large teams. I’d certainly give it a shot if I were hired by a site that had it already in place (I’m a software engineer, not a release engineer and so the work is what matters) but I would have deep reservations about deploying ClearCase into a new team or as a replacement for an existing system. There are too many other options available that don’t have the overhead or down sides that I seen in this tool.