Confusing terms in Software Configuration Management (SCM)

Software Testing

Confusing terms in Software Configuration Management (SCM)

Un-managed software is prone to undesired changes. Due to this, there exists the practice of SCM (software configuration management). SCM involves controlling access and storing changes to software code, resources and project artifacts. There are a large number of software tools (both commercial and open-source) to implement SCM activities in a software development or enhancement/ maintenance project.Your software project most likely has a chosen SCM tool (a.k.a. version control software or revision control software). Now, SCM tools often use similar terms to mean very different key concepts. In order to avoid costly mistakes and frustration, it is critical for you to understand these concepts used in working with the SCM tool.

Repository and Project

A Repository is the storage area set up to contain files (and their versions) of all the projects. In case of teams, the Repository is set up in a network location, a server or in the cloud. The Repository in turn may contain zero or more Projects (both past and current). On the other hand, a Project contains all files (and their versions) of a single software project. A current Project would typically have active revisions to its files.

Trunk and Branch

The Trunk is the core set of files that constitute the current and past standards release of the software product. For example, a financial accounting product may have its Trunk baseline (see below) at version 4 and development work started on version 5. There may be a software project to develop enhancements on a particular standard release or maybe customize a standard release for a particular client. Such a project is not done using the Trunk because the Trunk represents the long term evolving product. Rather, the basic set of files is copied from a particular Trunk release and work started on this set of files. This set of files represents a Branch. If the Branch project is successful (e.g. a set of enhancements is correctly developed), the team may decide to update the Trunk with the changes implemented in that Branch’s files. If the Branch project is not successful, the team may decide to simply discard that Branch and the Trunk would remain unaffected.

Add, Update and Commit

The Add operation takes a file or a folder from the user’s local machine and uploads it to the Project in the Repository on the server. The SCM tool actually writes to the server only when the user performs the Commit operation. The Update operation takes the current version of the file or folder from the server and stores it in the user’s local machine. The Add operation is done once on a file but the Update operation is performed repeatedly to get the latest changes done by other users. The Add, Update and Commit operations can also work recursively (i.e. on the entire folder hierarchy).

Delete and Purge

The Delete operation does only a logical delete of a file or folder in the Project in the Repository on the server. This file or folder is simply marked as deleted and its revision history is maintained. Therefore, any revision of such a file or folder maybe restored in the future. On the other hand, Purge removes the file or folder as well as its revision history from the server. A Purged file or folder is lost forever. Both Delete and Purge operations make changes on the server only when the user performs the Commit operation.

Checkout and Lock

If a user wants to modify a file or folder on the server, he/ she has to check it out first. The Checkout operation makes the local file/ folder editable so that the user may modify it. Checkout should be performed only after Update so that the user gets to work on the latest revision of the file/folder. Checkout on a file/ folder does not prevent another user from checking out the same file/ folder. Lock has to be used for the same. Both Checkout and Lock operations can also work recursively on the folder hierarchy. After making changes to the file/ folder, the user has to perform the Commit operation to actually write the changes to the server.

Overwrite and Merge

If the base revision of the modified file/ folder a user is trying to commit to the server is different from the current revision in the server, it means that another user modified the file/ folder while this user was still working on it. This results in a conflict. There are two options to resolve a conflict. One is to over-write the previous version. This option discards the changes made in the previous version. So, the better option may be to use the Merge operation. This combines the changes made in both the revisions. After making changes to the file/ folder, the user has to perform the Commit operation to actually write the changes to the server. However, the Merge operation works only on text files. It is not possible to merge two binary versions. Therefore, if a user wants to change a binary file, it is good to do the Lock operation on the file first so that any other user cannot change the version while work is in progress.

Revision Number and Message

Whenever a user does a Commit operation on a file/ folder in the Project, the SCM tool automatically assigns a new Revision Number to the latest version of the file/ folder. The user may also write a Message that gets stored along with the new Revision Number. The Revision Number is meaningless with respect to the particular change applied in the new version. Therefore, the user better write a meaningful description of the change in the Message. The Revision Numbers and Messages can be applied recursively on the folder hierarchy in Label and Baseline operations.

Label and Baseline

Whenever an interesting event (such as files ready for integration testing) occurs, a user (likely an administrator user) may Label the files/ folders appropriately. Labeling multiple files/ folders creates a new artificial version of each file/ folder with the Label as Message. Therefore, the Label operation creates a logical set of files/folders. In future, users may change some files or folders but it is always possible to extract the labeled set. The Baseline operation is similar to the Label operation but happens less often. For example, when files ready for release to customer. Baseline set is also used to create a Branch. Both the Label and Baseline operations are almost always applied on a set of files/ folders recursively on the folder hierarchy.

I hope that after reading this article, you have a better understanding of terms used in SCM and are able to use your project’s SCM tool with more clarity.

Inder P Singh

About Author:
Inder P Singh is presently senior software testing consultant and senior test program manager with expertise in providing end-to-end software testing services. In the past, he has worked as senior manager/ testing head with reputed product-based and services-based companies in India, UK and the US. His role encompassed pre-sales consulting, projects feasibility study, testing projects launch and their ongoing program management while reporting to the client management. Inder’s core competencies are functional test automation and performance/ load testing. He is also keenly interested in software security testing and software quality management. His blog is called Software Testing Space and he can be reached at  isingh 30 (no spaces) at  g mail dot com.
Leave A Comment