In the beginning, there was Chaos...
In the early days of software development, everyone did their own thing. Hardware was scarce and software projects were small. But soon, when multi-programmer projects became common, configuration- and change-control problems started rearing their ugly heads. When two programmers tried to edit the same source-code file, the inevitable happened and changes were over-written or lost. Initially, manual (human-based) change-control processes were instituted with varying degrees of success and varying degrees of overhead.
In order to solve the configuration-control problem, various software products and utilities attempting to address the problem were soon introduced:
- In the late 1950s, CDC introduced UPDATE, and IBM produced IEB_UPDATE - rudimentary tools to be certain, but they laid the ground-work for what was to come
- In the early 1970s, a Unix tool known as "make" was introduced
- Around 1972, Bell Labs introduced the original algorithm for "diff"
- In 1975, Mark Rochkind of Bell Labs wrote a paper for the IEEE which introduced SCCS, the first true source-code revision system (historical note: although the system itself is considered obsolete, it's file-formats endure to this very day in some modern SCM products)
- In the early 1980s, RCS was developed at Purdue University as a free (and open-source) alternative to SCCS. RCS is the direct predecessor to CVS and PRCS
- In 1985, Larry Wall (of Perl fame) introduced "patch"
- In 1986, Concurrent Version System (CVS) was created
- At the beginning of the new millennium, Subversion was released as well as viable distributed revision control systems like GNU "arch" and Bitkeeper
These products provided an evolution of functionalities and concepts that have moved the field of SCM forward in leaps and bounds.
In this paper, I will describe the concepts of the current solutions and propose requirements for a software solution that will extend SCM into the database configuration management realm.
An element is a file, directory or other entity under SCM control that allows the SCM to store version changes for that element. See Figure 1.
A version is a specific iteration of an element. Versioning allows us to identify a timeline of changes to an element and gives us the ability to rollback changes to a specific version or point in time. See Figure 1.
The repository is a container of elements with all of their associated changes and versions. See Figure 1.
A baseline is a collection of a single version of each element that together make up a known set configuration of the entire application (e.g. a GA release of the product). See Figure 2.
A collection of specific versions of certain elements. A Tag can be associated with a logical (human readable) name. Also called a Label. See Figure 2.
The collection of the latest checked-in versions of every element in the repository. See Figure 2.
An action that reserves a specific (usually the latest) version of an element. This allows the user to then edit the source-code of the element. It also locks the element so other users cannot modify it. Usually, the user can add a comment describing the planned change to the check-out action.
The opposite action to Check-Out. This returns the user's newly edited source-code to the repository (a new version is created) and unlocks it so other users may check-out. Usually, the user can add a comment describing what has been changed to the check-in action.
The user may decide to back out of the change altogether. In such a case, a rollback action will be issued which will release the lock on