We will use the CMMI (Capability Maturity Model Integrated) definition of Configuration Management:
The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items.
At its heart, CM is intended to eliminate the confusion and error brought about by the existence of different versions of artifacts. Artifact change is a fact of life: plan for it or plan to be overwhelmed by it. Changes are made to correct errors, provide enhancements, or simply reflect the evolutionary refinement of product definition. CM is about keeping the inevitable change under control.
Can you "do" CM using only Version Control tools—absolutely! But the better you understand the principles, and the better you understand what tools can do for you and how they have evolved, particularly over the last 10 years or so, the easier you can make your life.
Most Popular Tools
Sometimes we're asked what are the "top three version control tools today." People expect us to answer what our personal top three favourites are—instead we tell them what the three most popularly used ones are. The provocative answer is...(drum roll please):
#3: CVS—because it is "free", and comes "out of the box" on most Unix/Linux systems (note this is slowly evolving towards Subversion)
#2: VSS (Visual SourceSafe)—because it comes as "part of the package" with many purchases of Microsoft's Visual Studio IDE
and the #1 version control tool in use today is ...
"Version control? What's that mean? Isn't that what backups are for? I already do that!"
While this may seem apocryphal, one of us very recently came across an organisation where some teams are still using just the file system to do version control—manually copying changed files between directories, etc.
History of Version Control and Configuration Management
Principles of Configuration Management have been understood throughout civilisation, particularly in the military arena. A thread on CMCrossroads points out the discovery of timbers from ships from the time of Nelson and Napoleon showing identification of configuration items and an understanding of management of configurations which was perhaps one contributing factor to Britannia ruling the waves in that era!
The OS/360 development team made famous by Fred Brooks' "Mythical Man Month" and working in the 60's, did configuration management but without direct tool support. They used what they called a "vault" system, which was simply a set of "backed-up" storage areas (integration workspaces) for each "promotion level" they needed. They had a development "vault" (an integration workspace for development), a more formal "vault" for what they would periodically release to integration+test, and finally a "release" or "production vault" for what they actually shipped.
The first widely used tool for version control was SCCS, originally written by Marc Rochkind in 1972. The simple model of being able to check-out and check-in, saving versions and showing differences between them, was a big advance on previous manual methods.