Software Configuration Management SCM) is a specialization of configuration management in all activities and results in the field of software development as well as their use in products. This includes, among other things, the appropriate consideration of docking native product components and their variants (e.g. via compatibility matrices) throughout the entire product life cycle. Basic objects that an SCM tool must be able to map are project, file, configuration unit, baseline, and product.
Project
A project is characterized by its beginning, end and scope. Because development usually refers to something bigger, this part is often called a subproject, change, change order, change request, task, or similar. Although it is possible to get by with only one hierarchical level, this usually makes the work cumbersome. For this reason, the tools specify several levels or allow them to be freely defined in order to ensure delegation to other people or teams. Typical hierarchies are project task subtasks.
---
File
In SCM, the file is usually seen as the base object that needs to be managed. In addition to simple versioning, it is often necessary to branch out and merge development again in order to accelerate the production process. In detail, however, there are other problems that are not taken into account when selecting the SCM tool, but can lead to problems afterwards. It starts with the topic of renaming the file, which is often not possible with simple version management. The problem area also includes moving to another directory or deleting. Directories are solved differently, sometimes ignored. The latter can either only appear in the mapping to the file system or actually be versioned as objects as well.
The transfer between the version control and the file system causes further complications if more than one type of operating system has to be supplied. Problem points are upper and lower case or their conflicts as well as special types such as symbolic and hard links, devices, pipes, etc. Other places that need to be considered are fonts for file names and content, which must be handled separately, or timestamps. Because the operating systems support different times, Windows e.g. the creation time, but Unix does not, such things would have to be handled, but are omitted for most products. However, the modification time is more often taken into account because it can take on two possible values when it is played out to the file system: the actual time or the modification time before archiving. The time to choose depends on the build system the user is using.
Baseline
Because there are numerous versions in the archive, there must be a mechanism that also identifies the related versions. This is known as “tagging” or “baselining”. The possible variants that lead to its creation are numerous. Sometimes a view of the versions with rules is created and then marked. Alternatively, rules can also lead to this. The most sensible method, which is rarely sufficiently well supported, is change management by means of projects in which changes to processes may only be carried out when the processes are mature.
Product
The goal of software development is a product that usually consists of one or more programs. The subdivision by product is necessary so that the SCM tool can be used for multiple applications without having to be installed multiple times. For most real developments, the classification by product is too rough. For this reason, there are mainly subcategories, whereby this hierarchy often serves as a hook for access permissions.
SW configuration unit
In this context, SW configuration unit means a suitable, selected unit that is distinct from other SW configuration units (e.g. Operating system, drivers …). This configuration unit is related to “any combination of other configuration units of hardware, software, infoware, or services”. SW configuration management is therefore not bound to a specific application context and system configuration per se.
Other properties
Practically always, depending on the philosophy of the tool, there are other objects. These often concern the relationships between the objects or the view of them, especially the files (views, worksets). It can be assistance for dealing with certain operating systems, group permissions, delegations, external processes, etc. The problem of how to make version changes to databases remains unresolved. The pragmatic approach is to manage the SQL scripts, but it does not solve the problem of having to provide both the data model difference to the predecessor and the rebuild.
