Aka. SCM or Configuration Management (CM). Concerned with the policies, processes, and tools for managing changing software systems. Needed because it is easy to lose track of what changes and component versions have been incorporated into each system version.
- Configuration Item (SCI)
Any artifact placed under configuration control. Covers source files, build scripts, configuration files, shared libraries, and tool versions. Has a unique name. The repository stores all historical states, not just the current state. - Version
A distinct recorded state of an SCI. Each submission after modification creates a new version rather than overwriting the previous one. Identified by item name and version number (e.g.,C1.0,C1.1,C1.2). - Baseline
A fixed, named snapshot of a complete set of component versions forming a working system at a point in time. Immutable once established. Any change to a component produces a new version belonging to a new baseline. Guarantees exact reproducibility of any past system state. - Codeline
The full version history of a component and its dependencies. A component version compatible with one dependency version may not be compatible with another. - Mainline
The authoritative sequential progression of baselines over time. Branches diverge for isolated work and merge back to produce the next baseline.
Versions are instances of SCIs. A Baseline locks a specific set of versions into a coherent system snapshot. The Mainline is the ordered sequence of such baselines. A Codeline is the per-component view of version history, including dependencies.
Repository
Shared store for all versioned project artifacts.
Stores:
- All source code versions
- Configuration files, build scripts, shared libraries, toolchains
- Database of version info: who changed what, when, and why
Version Control
The practice of tracking and managing changes to software artefacts over time.
Version Control System
Aka. VCS. Records each modification to source files with:
- Timestamp
- Author identity
- Descriptive message
Enables:
- Retrieving any historical version.
- Comparing differences between versions.
- Reverting to a prior state if a defect is introduced.
Types
Centralized
Single server holds the authoritative repository. Developers check out and check in files.
Access control per path is simple to enforce because all reads and writes pass through one server. Administrators have a single audit log, a single backup target, and one authoritative state to reason about. Linear history is the natural default, which simplifies release tracking.
A single point of failure. Cannot work offline as every commit, diff, and history query requires network access. Branching in early implementations copies the entire tree on the server, making it expensive for large codebases.
Examples are CVS and Subversion.
Distributed
Each developer holds a full clone of the repository locally. Files are shared through a remote. There could be many remotes for a single project. And remotes can be self-hosted.
Full repository history, commits, diffs, and log queries can be executed locally. No single point of failure. Multiple remotes let independent workflows, forks, and mirrors coexist without central coordination.
The initial clone transfers the entire history, which is expensive for large repositories. Binary assets accumulate as separate snapshots without delta compression, causing disproportionate storage growth over time. Managing multiple remotes and non-linear histories demands a steeper learning curve than a single-server model.
One example is git. Created by Linus Torvalds in 2005 to manage the Linux kernel source.
Branching
A branch is an independent, stand-alone version of the codebase. Created by a developer, to work on a feature independent of the master branch.
Branch files become the repository files when they are merged. Thorough testing is done before merging a branch.
System Building
The process of creating an executable system by compiling and linking components.
Three environments:
- Development system
Development tools; developers check out code into a private workspace. - Build server
Builds definitive executable versions. Developers check in code before building. May use external libraries not in VCS. - Target environment
The platform on which the system executes. May differ in hardware or OS from the development system.
Minimizing Recompilation
Build tools compare modification timestamps (or checksums) of source vs. compiled files:
- Compiled newer than source → no recompilation needed.
- Source newer than compiled → recompile source.
- A dependency (e.g., header or class definition) newer than compiled → recompile the dependent.
Checksums allow parallel builds; timestamps may not.