The software development process involves change.

Attitudes towards the software development process have undergone a sea change during the past four decades.

Software engineers used to live by the credo "Make a plan and stick with it -- never waffle," and

"Requirements must be frozen -- how else will we know what to code?" 

Changing times bring changes in their wake. Now, software professionals say, "Plans are living documents-they will be in a continual state of change as project knowledge increases."

Software requirements are never frozen.

They merge, morph, evolve, expand, extend and get enhanced.

As long as artifacts of software development can undergo change, software engineers will need some method of managing this change. This is where SCM comes into the picture.

SCM plays a key role in improving the quality of delivered products.

Hence, understanding SCM and knowing how to implement it in your organization and on your projects is a critical success factor in software development.

So what benefits does SCM bring to a software organization?

SCM benefits an organization in four areas: control, management, cost control, and quality. These four benefits are mapped to an organization's overall goals and objectives when the decisions are made to bring a SCM tool in-house.

The features of SCM tools further support these benefits. In this topic we’ll see how SCM processes and tools contribute to benefits in the areas of: control, management, cost and quality.

How does check-in help in SCM? Let’s see…

After the user creates a new file or works on a checked-out file and makes changes, he or she should check-in the file into the tools database.

Check-in allows users to: One, add comments to check-in dialog box to be stored as file history, Two, allot version numbers, and Three, associate revisions with a specific promotion group, if required.

The tools database accommodates all the versions of the file including the latest version. The checked in revision becomes the tip revision of the archive and is assigned the next highest number in sequence.

Only after a file is checked in, can other users check it out to make their changes. Check-in ensures that the changes are available to all the users. However only one user can checkout the file at a time, unless multiple check-outs are permitted. 

Why is check-out important in SCM? Let’s see…

If users wish to make changes to a file they must first check it out of the tools database. When users check-out a file, the tools database places a writable copy in the users working folder. Users can browse, edit or print the checked-out file.

A file that is checked-out cannot be simultaneously checked-out by anyone else, unless the installation has been set up to allow multiple checkouts. Check-out prevents users from overwriting each other’s changes.

To compare changes you can generate a difference report.

With a difference report you can visually compare the difference between two files or revisions, for example, between various versions of the file and the working copy or between two or more ASCII text

files. The display shows the added, changed and deleted lines in contrasting colors.

Difference reports serve several useful purposes. They can be used to determine the changes made to a file before checking it in. These reports also help confirm which of two revisions is newer if you are unsure of the timestamp. Finally, they help identify differences between revisions of the same file or between two files.

The process of using one base file or a set of files for two or more development activities is called branching.

Branching can be used for the following: Firstly, to build customized versions of a project, like when customizing an application for two or more clients and Secondly, to create parallel versions of a project, like porting one application to two or more operating systems.

Merging is the inverse of branching.

Merging is a process of combining two sets of changes to create a new file. Conflicts have to be resolved manually; the tool will show the conflicts visually.

Merging can be used to bring back the changes made in the branched files to the main files. Alternatively, it can also be used to bring the changes made to the same file by two or more persons.

Labels identify projects.

A label may be defined as a string used to identify a project. A label is a more descriptive name than a version number. All the files in the project are labeled with the same string.

Labeling a project is a useful way to freeze a moment in the project development life cycle.

Though labeling of a file is possible, it is not recommended as this can lead to confusion. 

Keywords can be used for search and change commands.

Keywords are used to automatically update some parts of the information in the header or comments stored in the source file itself. The tools database replaces the keyword with the relevant information each time the file is checked in.

Sharing files is a good alternative to branching and merging.

Sharing files in the tools database allows one file to be part of two or more projects at the same time. The master copy of a file resides in the VSS tools database. However the file is equally accessible to all the projects that require it.

If a change is made to the shared file, it is propagated to all the projects sharing the file. This feature saves time and resources by avoiding duplication of effort and storage.

How does the check-in and check-out model work? Let's see...

In the check-in, check-out model, the user works with a repository and a file system. The check-in, check-out model focuses on version support for individual files. Creation of new versions is controlled by the repository tool and files are stored in the repository after versioning.

Files in repository cannot be directly accessed. Users have to retrieve or check out, a version of a file from the file system in order to access its content. Files can be retrieved for read access, let’s say, for the user to examine a design document or for the compiler to access a file that has been included by another file. Files can also be retrieved for write access.

If files are checked-out for write access, concurrency control mechanisms of the repository coordinate multiple retrievals for making changes to CIs. Changed CIs can be stored back into the repository, that is, checked in, resulting in a new version of the file. However, there is an initial point where the CI is "added" to the repository to be subsequently handled.

The check-in, check-out model provides different conceptual primitives for versioning of files.

First there is an evolution of a sequential version history, also referred to as 'revisions'. This is followed by the creation of version branches or parallel version sequences that have as their starting point a particular version in an existing branch, but evolve independently. The branched versions merge into a new version, if that is required for a project or continue branching sequences if they represent parallel development activities. The result is a version history for files that has a graph structure. This structure is referred to as a version graph and is illustrated. 

Concurrency control implies controlling the retrieval of modifiable copies of files from the repository.

The latest version of a branch can be retrieved for modification and the branch is locked. Branch locking guarantees that only one person at a time is in the process of creating a new version for a particular branch. When the modified copy is checked in, a new version is added to the branch and the lock is released.

Alternatively, a version can be retrieved as the initial version of a separate branch. This may be

desirable when one developer is making a major change, locking the original branch over a long time, and a second developer is prevented from making a quick bug fix until the first change is completed. Once both modifications are completed and checked-in, the two changes can be merged.

While a retrieved file resides in the file system, it is outside the control of the S C M system. Access control and write-locking mechanisms of the file system are relied upon to guarantee exclusive access for modifications. In addition, an S C M system may support access control on the repository. An access control list may determine whether a particular person is permitted to check out a file for modification.

Any change requested by any user follows a predefined Change Request Process before it comes into implementation.

The user or client requests a change. The change request is then taken up by the Change Control Board that evaluates the Impact, Risk and Priority of the requested change. Once the Change Control Board decides on the changes, the project manager approves the change and the team manager gets involved in planning & managing the effort due to the change request. The implementation plan is drawn up and the check-out configuration items are logged into the dynamic folder of the user. The team then makes the changes requested and reviews the changes made. The check-in configuration items are logged in and a new baseline point is established