The history of software configuration management (SCM) can be traced back as early as the 1950s, when CM (configuration management), originally for hardware development and production control, was being applied to software development. Early software had a physical footprint, such as cards, tapes, and other media. The first software configuration management was a manual operation. With the advances in language and complexity, software engineering, involving configuration management and other methods, became a major concern due to issues like schedule, budget, and quality. Practical lessons, over the years, had led to the definition, and establishment, of procedures and tools. Eventually, the tools became systems to manage software changes.[1] Industry-wide practices were offered as solutions, either in an open or proprietary manner (such as Revision Control System). With the growing use of computers, systems emerged that handled a broader scope, including requirements management, design alternatives, quality control, and more; later tools followed the guidelines of organizations, such as the Capability Maturity Model of the Software Engineering Institute.
[[make (software)|make]].[[diff]] algorithm.[[Patch (Unix)|patch]] (around 1985, Larry Wall).Until the 1980s, SCM could only be understood as CM applied to software development.[5] 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.
SCCS (first released in 1973) and DSEE (considered a predecessor of Atria ClearCase), described in 1984,[6] are two other notable VCS software tools. These tools, along with Revision Control System (RCS), are generally considered the first generation of VCS as automated software tools.
After the first generation VCS, tools such as CVS and Subversion, which feature a locally centralized repository, could be considered as the second generation VCS. Specifically, CVS (Concurrent Versions System) was developed on top of RCS structure, improving scalability of the tool for larger groups, and later PRCS,[7] a simpler CVS-like tool which also uses RCS-like files, but improves upon the delta compression by using Xdelta instead.
By 2006 or so, Subversion was considered to be the most popular and widely in use VCS tool from this generation and filled important weaknesses of CVS. Later SVK developed with the goal of remote contribution feature, but still the foundation of its design were similar to its predecessors.
As Internet connectivity improved and geographically distributed software development became more common, tools emerged that did not rely on a shared central project repository. These allow users to maintain independent repositories (or forks) of a project and communicate revisions via changesets.BitKeeper, Git, Monotone, darcs, Mercurial, and bzrare some examples of third generation version control systems.[8]