Developing Programmers .com

Software Configuration management is all about storage and management of a revision history of a project. The buzzword “Configuration Management System” (”CMS”) can refer both to a complete process incorporating whatever reporting and storage needs the project has, or to software applications that address some or all of these needs. Note that “CMS” is also used to abbreviate “Content Management System”, which is a somewhat different beast and should not be confused.

In fact, according to Wikipedia, even the phrase “Configuration Management” has a wide range of meanings. One is:

The control and adaption of the evolution of complex systems. It is the discipline of keeping evolving software products under control, and thus contributes to satisfying quality and delay constraints. Software configuration management (or SCM) can be divided into two areas. The first (and older) area of SCM concerns the storage of the entities produced during the software development project, sometimes referred to as component repository management. The second area concerns the activities performed for the production and/or change of these entities; the term engineering support is often used to refer this second area.

This is the definition of most interest to us, a colloquial software engineer’s idea of what CMS means.

Typically, Configuration Management is is handled by specialized CMS software tools. These are often referred to as “Revision Control Systems” because one of the earliest CMS tools was called that. They are also sometimes called “SCMs”, “Source/Software Code/Configuration management” systems.

A common element in CMS systems is storing each revision of a project as it develops, so it is possible to see who changed what and when and to recall any revision of an application. A “revision” need not be a released version; it might be just a small change to the project.

Why Bother

Pros of keeping each revision:

• You can find out when a bug was introduced.
• If two people edit the same file they are protected from wiping each others changes.
• You can see who wrote (who’s to blame for) particular sections of code.
• You can re-create old results; either for accountability or to reproduce results from a customer who has an earlier version of the software.
• You have an audit trail of the creation process of your project, solid proof that it’s your work.
• You can review how your software evolved and see trends in development.
• With check-in comments you can see what you (or others) were thinking when you checked in various changes.
• You can call up a summary of what others in the team have changed since you last looked, to keep up to date.
• The CMS can serve as additional backup copy if kept on a separate computer.
• Check-ins can be matched against bug “ticket” list for history of which change fixed which problem.

Cons of revision control:

• Requires disk space (although usually only “diffs” are stored so you don’t need that much disk space).
• Most systems require formal “check-in” of code (ie., a “check-in” command and entering a log message).
• Managers might notice that they can monitor how many lines of code is contributed by each person. Many don’t realise that this is a terrible measure of productivity: if I’m fixing up someone else’s code I often check in a negative number of lines of code.

Who Should Use A CMS?

CMSs are useful for just about anyone working on “projects” on a computer. “Projects” are typically programs but can also be HTML documents, whole web sites, text files, your thesis, or just about anything.

A CMS should be considered essential when developing software in a group of more than one person. Even working solo I prefer to use a CMS — I just don’t trust myself to remember when or why I did things. I also like being able to take risks like simply deleting old code rather than commenting it out; safe in the knowledge that the code I’m deleting is stored in the previous revision in the CMS.

When I started my current job at a university I was rather shocked that they didn’t use a CMS; and so was another co-worker who had also came from industry. We had a CMS set up quick sharp and were soon running classes on how to use it: Even people who initially thought it was a waste of time were won over later that year when they experienced the inevitable data loss that comes from multi-person projects that don’t have revisions managed properly.

Optional Features of CMSs

Different CMSs are set up with different needs in mind. Usually the needs relate to how the group works and what kinds of formal process they use.

Optional features that in practice every good CMS has include:

• Being able to “tag” significant revisions by some name you choose; for example “Release 3″ or “Code-Freeze-for-2005″.
• Handling “branches” of the code base; for example a branch of an application for a second platform or simply to back-port features from the latest version to previous releases. Branching generally includes automatic(ish) merging of changes from one branch into another, to make it easy to back-port features or re-merge two branches.

Features that tend to distinguish different CMSs include:

• Implicit check-in by modifying files — No need to use a “check-in” command, the file system IS the CMS.
• Formal Process Support — Actively keeps branches for code as it progresses through acceptance stages (for example “just checked in”, “passed auto testing”, “peer reviewed”, and “part of final code base”).
• Check-in testing — Might run test software on the code for you to reject code that doesn’t work.
• File locking — Prevents two people modifying the same code. Some systems allow this freely and are careful about merging changes. Others prevent two people editing the same file. Others let you select which way you prefer to work.
• Integration with other tools — Most of these systems have third party GUI and web front ends and many have either built in or third party ticket/bug tracking software as well.

Find What Works For You

I have compiled a list of a range of CMS options that you might like to look at. I suggest you shop around as there are many good systems and they all have their own strengths and weaknesses. The list is far from complete as there are so many CMS tools out there. If I haven’t mentioned a system it doesn’t mean the system is no good; it just means I don’t know much about it. Opinions are of course my own and subjective; your milage may vary.

• Aegis — (GPL-Free, *nix only), — A colleague at work has used this and highly recommends it. Aegis is aimed at larger scale projects with many users and has support for formal test and review methods.
• CVS — (GPL-Free, *nix, Win, Mac) This is probably the most widely used CMS because it is free, old and relatively lightweight. It doesn’t have specific support for formal process and it doesn’t by default do locking and so the server doesn’t need to keep track of who is making what changes until they try to check in code. This makes it very popular in open source software where people frequently “tinker” so not all developers want to submit changes back to the main code base. Has some oddities like not being able to “move” a file in one atomic commit. Data is stored in plain text files which with patience you can learn to hand edit to do complicated or custom things. Various third party GUIs are available.
• Darcs — (GPL-Free, *nix, Win, Mac) A new system by David Roundy. I haven’t tried this system but the author says: “Darcs is decentralized, based on a ‘theory of patches’ with roots in quantum mechanics. Darcs is free software, licensed under the GPL.”
• MS Visual SourceSafe — (Commercial but often available bundled, version from Microsoft is Windows only but third party suppliers offer compatible Mac and *nix versions) In a previous job I used SourceSafe for a time. It had a fairly ordinary feature set, an integrated UI that was nice, and a back-end database that kept having problems that required fixing. This was admittedly a while back, it may have improved.
• Perforce — (Commercial but available free for small groups, *nix, Win, Mac) — I’ve never tried Perforce myself but a glance at their web site tells me that it uses a similar change model to Subversion and also has integrated bug tracking and a GUI.
• Rational ClearCase — (Commercial, *nix, Win) Yes this is by the same people who wrote “Rational Rose”. This product has “lifecycle” support that includes automated builds and testing. It also integrates into the file system to create “transparent” revision control where just saving a file will automatically commit that change. I gather from friends that use this that it’s big and complex and powerful; which is sometimes a good thing and sometimes very frustrating. Complexity has its pros and cons.
• RCS — (GPL-Free, *nix, ?) I don’t actually recommend this system but have included it because it’s an important part of CMS history. RCS is the predecessor to CVS and works only on individual files, not whole directories. It is rarely used these days but a lot of current systems are influenced by it so it’s worth knowing the piece of history.
• Subversion — (Free, *nix, Win, Mac) This is becoming increasingly popular as it is a rewrite of CVS aimed at solving its historical quirks while retaining a similar “feel”. It doesn’t do locking (although locking is a feature that’s “coming soon”). It doesn’t do formal process but has “hooks” that let you call scripts on various events so you can add formal process tools to it if you wish. Subversion does everything I expect a CMS to do and no more; which means it does its one job very well and handles extension by playing nice with other programs rather than by trying to do everything itself. This is my personal favorite CMS because it is robust, lightweight and leverages Apache2’s security and login systems.
• Vesta — (GPL-Free, *nix only), — I’ve never tried Vesta but according to their home page it incorporates a distributed build process (a “Make” replacement with cool toys added) into the CMS system.

Conclusion

No professional methodology is complete without source configuration management, and no professional programmer is at home without some form of CMS software. It prevents a wide range of preventable mistakes in changing software both individually and in a group. I personally won’t edit software without it.

If you’re not familiar with CMSs then I recommend you try one of the free packages to get a feel for how they work. Responsible employers will expect you to be familiar with the concept of CMSs if not the specific package they use; and it’s worth knowing how to use CMSs just for your own peace of mind.

Updates

• 24 Nov 2005: The CVS and Subversion Combined Tutorial has now been posted for those interested in getting started with CVS and/or Subversion.
• 15 Dec 2005: The CVSTrac and Trac Combined Tutorial