This is the first in what may (or may not) be a series of posts on source control written to prepare for a presentation I'm doing on this topic.

Source control is one of the fundamental elements of any professional software development effort. Desirable in single person development, it is mandatory in a team environment.

The naive view of source control is that it is a backup mechanism to guard against the loss of work due to factors such as failure of a development system. This is an important function but represents only a small fraction of the worth of a source control system. The majority of the value provided by source control comes from using it to manage change, control complexity and support collaboration.

Making multiple developers into a team requires some co-ordination. Part of this is the dull project management bit controlled by people who think the name PRINCE II is terribly witty. Although quite important in building a useful software system this is not the kind of co-ordination that concerns me (I shall later contradict myself by discussing integration of source control with work item/bug tracking, but I shall cleverly use another post to disguise this).

When you have multiple developers working on the same codebase you need a mechanism to propogate changes that is consistent and reliable. Failure to correctly distribute changes between developers will result each developer having a diverging view of the code, taken to extremes each would end with a unique system that could not be integrated with any other. Clearly this is sub-optimal. Source control provides a way to maintain a single point of truth with which all developers may synchronise, intergrating their latest changes and receiving those of other developers.

Source control is also essential for the management of multiple versions of a codebase. This is a common scenario where you must support existing releases of your system as well as develop features for the next release. Source control provides mechanisms that (when properly used) allow the challenge of maintaining multiple versions in parallel to be addressed.

In a small team a mechanism such as a network file share or email may suffice for distributing changes. Such a mechanism is going to be more work than using a real source control system and will be significantly more error prone. Source control systems are available at a variety of price points, and there are solid open source alternatives available.

This post has been rather light on specifics, later posts will elaborate on particular comments. There is one concrete piece of information to be taken away thought: Don't use Visual SourceSafe (VSS). It's not safe (or particularly visual), the pain and lost work choosing this because you already have it on DVD somewhere will vastly outweight the cost of obtaining something decent (Subversion is widely used and respected). If you must use Microsoft (or you have the budget) consider Team Foundation Server, which often seems as if they used VSS as an executable anti-pattern.