1 Software Configuration Management (SCM)

• SCM Activities

  • Version control

  • Build management

  • Environment management

  • Change management

We’re going to focus on change management and its relation to VC.

1.1 Codelines and Baselines

• A codeline is a sequence of revisions of a configuration item

  • In essence, a branch

• A baseline is a collection of component versions that make up a system.

1.1.1 Codelines and Baselines: Example

A baseline merges components that we have written (a version out of our codelines) with versions of 3rd party components that we employ.

1.1.2 Baselines

• A major challenge of SCM is coping with multiple baselines that must

  • co-exist and
  • be actively maintained.

• Major issues are

  • deciding when to “freeze” on a version of an imported library
  • tracking the transitive closure of dependencies from libraries that we directly depend upon
  • finding a mutually compatible set of versions among all those external libraries

2 The Strategic Use of Branches

Branches are not just for informal exploration.

2.1 Codelines == Branches

• Main trunk moves forward in time

• Each planned release is a branch from the trunk

  • continues forward through its maintenance lifetime

2.2 Change Management

• When do proposed changes become an official part of a version?
• When do changes propogate multiple versions?

2.2.1 Making Decisions

In large organizations, changes are approved by a Change Management Board.

E.g., the team working in an exploratory branch has demonstrated an attractive new feature.

• Should we adopt it?
  • If so, which of the version code lines should it be added to?

2.2.2 Change Propagation

Even in smaller projects, the issue of change propagation across code lines needs to be kept in mind.

• The whole “main trunk moves forward” idea presumes that most release changes are synced into the trunk:

• As a practical matter, someone has to decide whether bug fixes in older versions can and should be merged into later versions.

2.3 Merge Requests

Open source projects often have a structure of

• Core developers who manage the overall vision and quality of the project over an extended period of time.
• Contributors who are loosely affiliated with the project and may only pariticpate for limited periods of time.

Typically, the main release branches can only be modified by the core developers.

2.3.1 Contributors…

1. Create their own branch from one of the release branches.
2. Edit the code to add a feature of fix a bug.
3. Commit their changes in their branch.
4. Send a “merge request” to the core developers identifying the branch contianing their work and indicating the issue they were working on.

2.3.2 Core developers…

1. Accept the merge request.
2. Chock out their own copy of the relevent release branch.
3. Merge the changes from the contributor’s branch into that release branch.
4. Run tests and quality checks.
5. If the contributor’s contribution is approved, pushes those merged changes into the central repository.