Software Configuration Management

Software Configuration Management

Google Code University

(http://code.google.com/edu/tools101/scm.html#0.1_CM)

Audience and Pre-Requisites

This tutorial covers a tool commonly found in industry to support the software development process. 




The pre-requisites are significant programming experience with a language such as C++ or Java, and familiarity with Linux or Unix.

Configuration Management Situation

Configuration Management (CM) is a tool that is used to manage change. 




Let's say Bob and Susan are both tech writers and both are working on updates to a technical manual. During a meeting, their manager assigns them each a section of the same document to update.




The technical manual is stored on a computer that both Bob and Susan can access. Without any CM tool or process in place, a number of problems could arise. One possible scenario is the computer storing the document might be set up so that Bob and Susan can not both work on the manual at the same time. This would slow them down considerably.

Configuration Management Situation

A more dangerous situation arises when the storage computer does allow the document to be opened by both Bob and Susan at the same time. 




Here is what could happen:

Bob opens the document on his computer and works on his section.

Susan opens the document on her computer and works on her section.

Bob completes his changes and saves the document on the storage computer.

Susan completes her changes and saves the document on the storage computer.

Configuration Management Situation

This illustration shows the problem that can occur if there are no controls on the single copy of the technical manual. When Susan saves her changes, she overwrites those made by Bob.

Configuration Management Situation

This is exactly the type of situation that a CM system can control. 




With a CM system, both Bob and Susan "check out" their own copy of the technical manual and work on them. 




When Bob checks his changes back in, the system knows that Susan has her own copy checked out. 




When Susan checks in her copy, the system analyzes the changes that both Bob and Susan made and creates a new version that merges the two sets of changes together.

CM features

CM systems have a number of features beyond managing concurrent changes as described above. 




Many systems store archives of all versions of a document, from the first time it was created. 




In the case of a technical manual, this can be very helpful when a user has an old version of the manual and is asking a tech writer questions. 




A CM system would allow the tech writer to access the old version and be able to see what the user is seeing.

SCM system is critical

CM systems are especially useful in controlling changes made to software. 




Such systems are called Software Configuration Management (SCM) systems. 




If you consider the huge number of individual source code files in a large software engineering organization and the huge number of engineers who must make changes to them, it's clear that an SCM system is critical.

Software Configuration Management

SCM systems are based on a simple idea: the definitive copies of your files are kept in a central repository. People check out copies of files from the repository, work on those copies, and then check them back in when they are finished. 




SCM systems manage and track revisions by multiple people against a single master set.




All SCM systems provide the following essential features:

Concurrency Management

Versioning

Synchronization




Let's look at each of these features in more detail.

Concurrency Management

Concurrency refers to the simultaneous editing of a file by more than one person. With a large repository, we want people to be able to do this, but it can lead to some problems.




Consider a simple example in the engineering domain: Suppose we allow engineers to modify the same file simultaneously in a central repository of source code. 




Client1 and Client2 both need to make changes to a file at the same time:

Client1 opens bar.cpp.

Client2 opens bar.cpp.

Client1 changes the file and saves it.

Client2 changes the file and saves it overwriting Client1's changes.

Concurrency Management

Obviously, we don't want this to happen. Even if we controlled the situation by having the two engineers work on separate copies instead of directly on a master set (as in the illustration below), the copies must somehow be reconciled. 




Most SCM systems deal with this problem by allowing multiple engineers to check a file out ("sync" or "update") and make changes as needed. The SCM system then runs algorithms to merge the changes as files are checked back in ("submit" or "commit") to the repository.




Concurrency Management

 

Concurrency Management

 

These algorithms can be simple (ask the engineers to resolve conflicting changes) or not-so-simple (determine how to merge the conflicting changes intelligently and only ask an engineer if the system really gets stuck).

Versioning

Versioning refers to keeping track of file revisions which makes it possible to re-create (or roll back to) a previous version of the file. This is done either by making an archive copy of every file when it is checked into the repository, or by saving every change made to a file. At any time, we can use the archives or change information to create a previous version. Versioning systems can also create log reports of who checked in changes, when they were checked in, and what the changes were.

Synchronization

With some SCM systems, individual files are checked in and out of the repository. More powerful systems allow you to check out more than one file at a time. Engineers check out their own, complete, copy of the repository (or part thereof) and work on files as needed. They then commit their changes back to the master repository periodically, and update their own personal copies to stay up-to-date with changes other people have made. This process is called syncing or updating.

Subversion

Subversion (SVN) is an open-source version control system. It has all of the features described above.




SVN adopts a simple methodology when conflicts occur. A conflict is when two or more engineers make different changes to the same area of the code base and then both submit their changes. SVN only alerts the engineers that there is a conflict - it's up to the engineers to resolve it.

The first step is to install SVN on your system. Click here for instructions. Find your operating system and download the appropriate binary.

Some SVN Terminology

Revision: A change in a file or set of files. A revision is one "snapshot" in a constantly changing project.

Repository: The master copy where SVN stores a project's full revision history. Each project has one repository.

Working Copy: The copy in which an engineer make changes to a project. There can be many working copies of a given project each owned by an individual engineer.

Check Out: To request a working copy from the repository. A working copy equals the state of the project when it was checked out.

Commit: To send changes from your working copy into the central repository. Also known as check-in or submit.

Some SVN Terminology

Update: To bring others' changes from the repository into your working copy, or to indicate if your working copy has any uncommitted changes. This is the same as a sync, as described above. So, update/sync brings your working copy up-to-date with the repository copy.

Conflict: The situation when two engineers try to commit changes to the same area of a file. SVN indicates conflicts, but the engineers must resolve them.

Log message: A comment you attach to a revision when you commit it, which describes your changes. The log provides a summary of what's been going on in a project. 

Subversion Overview

https://docs.google.com/present/edit?id=0ATob-EjxU_d1ZGdjZmNxaGhfMjM1aGhyZnN3ZDM

Managing Source Code With Subversion

http://luv.asn.au/overheads/20050503-Subversion-slides.pdf