History of software configuration management

This article does not cite any references or sources. (January 2007) Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.

The history of software configuration management (SCM) in computing can be traced back as early as the 1950s, when CM (for Configuration Management), originally for hardware development and production control, was being applied to software development. The first software configuration management was most likely done manually. Eventually, software tools were written to manage software changes. History records tend to be based on tools and companies, and lend concepts to a secondary plane.

• Early 1960s or even late 1950s: CDC UPDATE and IBM IEB_UPDATE.[1]
• Late 1960s, early 1970s: Professor Leon Pressor at the University of California, Santa Barbara produced a thesis on change and configuration control. This concept was a response to a contract he was working on with a defense contractor who made aircraft engines for the US Navy.
• Early 1970s: Unix make.
• By 1970 CDC update was an advanced product.
• Circa 1972: Bell Labs paper describing the original diff algorithm.
• 1972, with an IEEE paper in 1975: source code control system, SCCS, Marc Rochkind Bell Labs. Originally programmed in SNOBOL for OS/360; subsequently rewritten in C for Unix (used diff for comparing files).
• 197x: Pansophic's PANVALET was an early source code control system for the mainframe market. They were based in Lisle, Illinois.
• 1975: Professor Pressor's work eventually grew into a commercially available product called Change and Configuration Control (CCC) which was sold by the SoftTool corporation.
• Revision Control System (RCS, Walter Tichy).
• Early 1980s: patch (around 1988, Larry Wall).
• 1984: Aide-de-Camp (ADC, later TRUEchange around 1990, Richard Harter).
• 1986: Concurrent Version System (CVS).
• 2000: Subversion initiated by CollabNet.
• Early 2000s: distributed revision control systems like BitKeeper and GNU arch become viable.

Until the 1980s, as can be seen from a source such as Software Configuration Management by J.K. Buckle (1982), SCM could only be understood as CM applied to software development. Some basic concepts such as identification and baseline (well-defined point in the evolution of a project) were already clear, but what was at stake was a set of techniques oriented towards the control of the activity, and using formal processes, documents, request forms, control boards etc.

It is only after this date that the use of software tools applying directly to software artefacts representing the actual resources, has allowed SCM to grow as an autonomous entity (from traditional CM).

The use of different tools has actually led to very distinct emphases.

• traditional CM for Software, typically around Change Mananagement (examples: Continuus, CVS or ClearCase UCM)
• line oriented management, based on patches or Change Sets (example: TRUEchange)
• focused on Derived Objects and Build Management (example: Base ClearCase/clearmake)

See also

• Revision control