MASARYK UNIVERSITY

FACULTY OF INFORMATICS

Master’s Thesis

SCM – Software Configuration Management

Marek Bokes

2006
Declaration

I declare that this thesis is the original author’s work; done independently by myself. All the
data, information and resources as well as publications used within the work are quoted with
a qualified reference to the origin.

Supervisor: Mgr. Miroslav Kubásek

ii
Acknowledgements

This way I would like to thank to the thesis supervisor, to Mgr. Miroslav Kubásek, for all the
guidelines and willingness.
Furthermore, my thanks goes to Udo Weber as well as to Hendrik Hempel for the
consultations regarding release management.

iii
Syllabus

Source code and configuration versioning itself as well as labelling technique is wide spread
in IT world of software development.
The have got full control over release management and consequently over deployment
process it requires the proper and suitable usage of a versioning system. Only with full
control and appropriate usage a release management can’t became a serious bottleneck of the
delivery process.
As a solution this master’s thesis project brings comprehensive package – a set of defined
approach of software versioning and release management besides cooperation with a bug
tracking system on one hand, and tools to follow this approach up, i.e. enable this to happen
in praxis, on the other hand.
Tools to work with versioning system are provided for both developer and configuration
(release) manager for specific platform and versioning system.

iv
Keywords

Software Configuration Management, Source Code Versioning, Software Deployment

Approach, Software Release Approach, CVS, Bug-Tracking System (Tool), Software
Release, Tag, Label, Revision, Consistency Checking

v
Preface

"Source Control is as much a way of thinking about software development as it is a tool. It

can facilitate parallel development and enable developmental isolation, but it can ensure
neither. Only by establishing and following through on a strategy can a team use Source
Control to its fullest potential"
-- The Microsoft Corporation

The managed way of source code versioning (also known as source code revision control) is
to be assumed as a general methodology of software development nowadays. This all is
covered by the software configuration management (SCM), which underlies the general
configuration management (CM).
Besides project management the area of SCM has quite similar importance. Its absence very
likely leads to serious issues during software quality assurance checkpoints or during a
delivery process in general. The eventual exposition is increased time to deliver of budget
cost. For fix price project this would be a disaster.
The amount of resources related to SCM - or CM in general - is quite rich, unfortunately
often offers only too general point of view or obvious facts. If one searches for specific and
directly applicable methodology he will fail, I assume. My such research and investigation in
the area failed either.
Rough idea of labels promotion what I’m aware of comes from approach implemented upon
versioning system of name Clear Case from the Rational1 company. The versioning system
itself is strictly commercial and expensive, on other hand the details of the approach were not
exposed to me or any public due to its proprietary nature.
With keeping the SCM’s importance in mind and based on absence of third party solution to
use or to build on, this master’s thesis project sets to itself an ambitious aim to provide (if
possible) generalized versioning approach and a set of tools to technically support that.

1
Note: The Rational Company developed several tools to support development, mainly to increase code quality;
in majority for UNIX system. The company has been bought by IBM.
vi
Table of contents

1 Introduction ..................................................................................................................................1
1.1 Overview ..........................................................................................................................2
1.2 Terminology .....................................................................................................................2
1.3 Common inappropriate usage of a versioning system ......................................................6
1.3.1 Case study ..........................................................................................................7

2 Source code versioning approach ................................................................................................8

2.1 General assumptions.........................................................................................................8
2.2 Main goals overview ........................................................................................................8
2.3 Actors ...............................................................................................................................9
2.4 Predefined label tags ......................................................................................................10
2.5 Who is applying the label ...............................................................................................10
2.6 Disposition of labels .......................................................................................................10
2.7 When to label..................................................................................................................10
2.8 When to label for a first time..........................................................................................10
2.9 The defect tracking cycle................................................................................................12

3 Preparing a release – deploying with versioning system..........................................................13

3.1 Considerations for following example............................................................................13
3.2 The approach ..................................................................................................................13
3.2.1 Zeroth step – put new release label across repository.......................................13
3.2.2 Step one – extract list of files to be released from bug tracking tool ................14
3.2.3 Step two – move the new release label, i.e. promote the revision.....................14
3.2.4 Step three – obtain all files of new release .......................................................16
3.2.5 Step four – build the release package ...............................................................16
3.2.6 Step five – completion......................................................................................16

4 Branching approach ...................................................................................................................17

4.1 General assumptions.......................................................................................................17
4.2 Proposed solution ...........................................................................................................17
4.2.1 When to create a separate repository ................................................................17
4.2.2 How to create a separate repository..................................................................18
4.2.3 How to work with separate repositories – the approach basis ..........................19

vii
5 The tools ......................................................................................................................................20
5.1 General assumptions.......................................................................................................20
5.2 Target versioning system................................................................................................20
5.3 Pre-implementation considerations.................................................................................22
5.3.1 The repository access approach ........................................................................22
5.3.2 CVS repository database format - files.............................................................22
5.3.3 CVS repository database format - folders.........................................................24
5.3.4 CVS repository database - location ..................................................................24
5.3.5 CVS local checked out copy admin structures..................................................24
5.3.6 The programming language ..............................................................................25
5.4 The implementation........................................................................................................25
5.4.1 Common functionality ......................................................................................26
5.4.2 The developer space tool – mklabel .................................................................27
5.4.3 The release-manager space tool – cvs_rcheck ..................................................28

6 The conclusion.............................................................................................................................33

7 Literature and resources ............................................................................................................34

A Appendix .....................................................................................................................................35
a. The cvs_rcheck script output ..........................................................................................35
b. An example of history graph of a file in VS repository.................................................36
c. The mklabel in action .....................................................................................................37

viii
 SOFTWARE CONFIGURATION MANAGEMENT

1 Introduction

The source code versioning itself, or also known as revision control is nothing special to be
explained these days. Thus let’s just briefly mention that it’s based on principle of several
versions – so called revisions – of the same object or unit of information; in the area of
software engineering it’s typically a source code of configuration file, binary object
respectively. A revision is ordinarily identified by its number. On top of this there lies a
concept of marking a revision by a tag, creating some kind of alias, virtual revision identifier,
the label. This happens on s single file level; while it’s an organized group of versioned
objects, together with wrapper handling versioning operations, it’s to be called repository, or
versioning system respectively.
The versioning system aims to store revisions, but this is not standalone functionality. This
way it provides overview of changes done, when and whom by – important thing, but the
focus to mention is the idea to assist or support the project (application) build, which is a part
of release management.
The release management has builds up on versioning system and provides as an outcome the
(software) release. Release is basically the delivery.
To deliver the release, it always goes through several project stages, i.e. the test stage for
instance. To each stage, to each its environment the release shall be deployable as smoothly
as possible. Any unexpected major issue cost the project a lot from project management point
of view.
Deployment is ergo one of the significant parts of the delivery process. But it’s fully
dependant on the release quality. The dependency consequently descends in cascade to the
versioning system usage. This is to be controlled by the release management.
So the résumé is that to have a full control over deployment and to avoid any issues during
that related to quality and the fullness of the delivered release, the release management is
major actor. Versioning system shall support the release management, but the prerequisite is
the right information about the versioned objects. And this needs to be stored by the most
appropriate actor, by somebody who actually does the versioning system interaction from
bottom perspective – by the developer.
While there is set approach of tasks and steps for each actor and the tools take place, the
release quality assurance is a must, inherited consequently to the deployment process either.
This master’s thesis provides both – the approach (or methodology) to follow up by the actors
and the tools to interact with the versioning system and check the consistency of versioned
data.
The deployment process this way employs the release management based on revisions control
to achieve desired quality the delivery.
1
 SOFTWARE CONFIGURATION MANAGEMENT

1.1 Overview
This master’s thesis report deals with the tools and their implementation in the last few
chapters.
The versioning and release management approach is set up after the terms are explained to the
reader.
The report begins with to the terminology explanation followed by examples of improper
versioning system utilisation (as observed this is right to be mentioned due to its still
occurrence in the real praxis).
The way of presentation of the terms has been chosen to be as much clear and structured as
possible with focus on visual interpretation2.
The experience shows the visual interpretation is much more comprehensible then a plain
text. Best instance of this approach is IT world’s focus on UML nowadays.

1.2 Terminology
Project - a compilation of (source, configuration, binaries, data etc.) files which make the
main application, e.g. Apache HTTP server including all modules, or a data warehouse
application consisting from combination of shell and PL/SQL scripts; technically any
combination of file to enable the application to run when deployed.
Delivery - compiled application/project including all necessary files3 needed for runtime,
configuration file(s), all other files4 supposed to be included in application package,
installation tool and it’s separate configuration eventually, release notes document,
installation hints as so called README file.
Source code – commonly a plain text file; basically a single file containing (source) code to
be compiled into a project.
Binary object – binary file in general; instances: precompiled executable (delivered by third
party for example), shared object or library (third party) - any part of a delivery of non-plain
text nature
Versioning system (VS) - a system which provides functionality to store, retrieve, compare,
annotate and other functionality upon an object5 to be versioned; possibly a wrapped on single
file revision control tool.
Repository (REPO) – structured and organized group of versioned object, a database where
versioning system stores the revisions of each versioned object; typically flat-text file based
database, often capable to be parsed by external tools

2
to follow this I dare have prepared drawings to visualize the discussed matter.
3
libraries, shared objects, scripts, third party delivered binaries etc.
4
examples: license file, data files etc.
5
(mainly) plain text files (source code, scripts, configuration, data) as well as binary files (executables, libraries,
binary data, archives etc.)
2
 SOFTWARE CONFIGURATION MANAGEMENT

Repository module - logical partition of repository represented by the name, commonly it’s
subfolder of repository of such a name (e.g. <repository_path>/dba); alias can be configured
for a module for ease of use or to checkout a list of modules on a single token demand, e.g.:
<repository_path>/dba_module;
dba_module ~ dba
<repository_path>/appl_module, <repository_path>/lib_module;
appl_module, lib_module ~ project)
Revision - internal version of a single file with identifier of number of format X.Y, where X
represents major release/functionality/branch number and Y is internal version counter
(technically Yth update/revision of a file unless set explicitly different way)

Figure 1.1 Shows growth of single file revisions number

Version – i.e. a software release, usually different and independent from any revision number,
release as a software package contains different revisions of single files; the format is for
instance X.Y[.Z], where X is major release number (main functionality significance), Y
means minor release number (iterations to fix/improve the X version), Z stands for eventual
hot fix version flag.
Label (tag) – considerable as a symbolic revision, chosen (alphanumerical) token occurring
on single file level and points to the specific revision of single file, points only to one revision
at a time, usually the same label which regards single release version - points to different
revision on a single file level for different files6. Single file is able to has got multiple labels
present – each capable point either to the same revision or to the different one7.

6
the reason is that not every file is being updated with the same frequency
7
each of labels appearing on a single file can represent different release versions where the single file is
participating in; on other hand the same revision can be used for several releases (usually in row) and updated
for some later version, e.g.: r1.1->v1.0.0; r1.2->v1.1.0, v1.2.0, v1.3.0, v1.4.0; r1.3->v1.5.0
3
 SOFTWARE CONFIGURATION MANAGEMENT

Figure 1.2 Label(s) presence on single file

Figure 1.3 Label presence from repository point of view; every single file has got the same label,
but pointing to the different revision
file1.c file2.c file3.c file4.c file5.c

1.1 1.1 1.1 1.1 1.1 LABEL

1.2 1.2 1.2 1.2

1.3 1.3 1.3 1.3

1.4 1.4 1.4

1.5 1.5

1.6

4
 SOFTWARE CONFIGURATION MANAGEMENT

Figure 1.4 Shows how the label puts different revisions of different files virtually to one
line. The line represents one specific release.
file1.c file2.c file3.c file4.c file5.c

have a look at
1.1
this ‘level’

1.2

1.1 1.3

1.1 1.2 1.4 1.1

1.2 1.3 1.5 1.2 1.1 LABEL

1.3 1.6 1.3

1.4 1.4

version
1.5
e.g. release v1.1.0

Label moving – technically means a change where the label is pointing to. When the label has
been moved points to other revision of the same single file. Technically could be realized as
atomic removal of existing label and creation of another one with the same name. Example
situation when the label moving is needed: developer did put an updated file after a bug
fixing into a versioning system and now needs to label the new created revision as test-ready
(instead of the previous one).

Figure 1.5 The situation when head revision of the file has been promoted to be test-
ready.

5
 SOFTWARE CONFIGURATION MANAGEMENT

Check-in – alias for commit in versioning system world; puts new revision of versioned
object into the versioning system. Common prerequisite is that versioning system needs to
know the object, i.e. it needs to be added firstly.
Check-out – gets local (so called working) copy of a project from versioning system. Checked
out can be whole project, module or subfolder. Many versioning systems support single file
check-out. In general technically it creates local copy as well as local control structures of
versioning system and its tools.
Update – gets specific or latest revision of file (or files) from versioning system; updates
local copies. Do not mismatch with repository side update, i.e. check-in. Common
prerequisite is checked out structure where the file(s) located is(are).
Defect (DT) - any bug within the software to be delivered8
Change request (CR) - any requested change in the functionality or code not based on a found
defect, in other words any update of functionality or code based on request to modify original
requirements

1.3 Common inappropriate usage of a versioning system

Usage similar to central storage point
• miscellaneous files are being checked in without having any structured approach; not
following any (or just weak) naming convention for files, directories and repository
modules neither
• revisions of the file are not stored as another commits of the same filename but as
several checked in files with different filename containing some post fix declaring a
version
Labelling usage misunderstood, rare or none
• release source code is checked out form versioning system, built, packaged9 and
consequently the package is checked in into a VS and labelled as the release
(excellent wrong versioning approach instance; to use VS for a release package
storage is quite ok, but the labelling concept is completely misplaced while used in
such a way and should take place much sooner before)
Developer’s semi-finished work saved into a versioning system, what prevents the freshly
checked out (the latest) project version even from being built or compiled;
New version to be released considered as the set of latest revisions and its retrieval from VS
exactly in this manner by “get latest” functionality (command).

8
to be considered as an official defect, not one found during unit test, usually found during an official project’s
test phase
9
usually package does not contain application sources but built binary objects; however even if package consists
only from some plain text files (of scripts for instance) the methodology of this kind is wrong
6
 SOFTWARE CONFIGURATION MANAGEMENT

1.3.1 Case study

(Note: The following case is not a real case study in right sense o the expression due to the
fact it really happened)
The deployment of new version on the application to the testing environment was triggered
by the regular schedule set up within the project. That requested the new release to be built.
Release manager announced the code-freeze timeline and at the certain time put a label across
the repository, tagging al the head revisions as the ones to be released as the new application
version. Onward he retrieved the release form versioning system and built it into the release
package. The package was deployed to the testing environment.
Shortly afterwards, during first test a new critical defect was found and raised. The team
decided to deliver an on demand hot fix due to quick possibility to fix that. The responsible
developer performed the defect fix in source code level, did commit the change into the
repository. Release manager issued extra hot-fixed release with the same approach as recently
for the regular release, what was deployed to the test.
Immediately the blocking issue was raised and the complete end-to-end testing stopped for
the day.
Investigation found the reason: during the hot-fixing some other developer(s) did commits of
source code not supposed to be released. But without having approach to select specific
revision for the release on single file level as well as without any consistency check they
didn’t have control over the delivered content. By this the deployment completely failed.

This example case shows clearly the need of appropriate usage of a versioning system and a
need of well defined, structured and clear software release management, i.e. good software
configuration management, which is subject to the overall deployment process and
application delivery.
This master’s thesis project asset shall prevent such a issues from happening.

7
 SOFTWARE CONFIGURATION MANAGEMENT

2 Source code versioning approach

2.1 General assumptions

(To be comprehended as the requirements on the approach itself and on the software tools
later on)
Approach supports the release management which is employed by the deployment process
from delivery point of view.
All changes or updates are to be tracked in a defect- or change-request-tracking tool. All
requested and changes done need to be entered in there.
A developer is requested to fill into a bug-tracking system a list of new, changed, removed
files and/or directories relevant to the defect/change request while he(she) describes the bug-
fix solution. Paths are to be relative to check out point.
The developer is requested to commit work daily. The minimal extent of checked in update is
to preserve ability to compile the application/project while any team member checks out the
latest version. Idea behind is to safely store all the work done to avoid any time (resources)
loss (and money loss consequently). On other hand there needs to be a solution how to ‘mark’
a revision as ready to be tested or released, because commonly it won’t be the latest one
always.
Moreover, there is a need to separate a developer from using various versioning system
commands and parameters due to labelling purposes as well as from entering the label
manually to avoid any incorrectness, even just mistyping.
Finally, the release manager has to have an ability to check the consistency between a
versioning system and a bug tracking tool. This is supposed to be as much automated as
possible. One repository could contain several systems (modules) included to the project
(application), but the release can regard single module, subset of modules respectively, thus a
feature to skip a check of list of modules is required.

2.2 Main goals overview

Let’s go shortly through the list in the structured way:
• include to the release and deploy consequently only and only the files of the revisions
which are supposed to be there
• enable at any time precise overview which revisions of the files make the release

8
 SOFTWARE CONFIGURATION MANAGEMENT

• enable retrieval of any version released in past on demand in future without explicitly
spent effort
• make possible to be in line with status in bug tracking tool
• catch-up any inconsistency between versioning and bug-tracking system
• to preserve ability of a developer do another commits after the one considered as test-
ready while the release consistency is not harmed
• basically have the full control over the objects released and the revision chosen on a
single file level

2.3 Actors
Human:
The basic role is the developer (DV). He is who provides the content to version and further to
be released. He knows the object to deliver, thus he provides the info which its revision is the
one to be labelled, i.e. released.
Configuration manager (CM) is the actor who checks the consistency between versioning
system and bug-tracking tool, performs needed interventions.
Release Manager (RM) is preparing the release by employing the data (tags) set by the
developer and applies the labelling techniques. Frequently the role is combined with
configuration manager, definitely not exclusive against role of developer (general situation on
small-sized projects).
Code migration responsible person (MR) the one responsible for merging changes within
different developmental branched. In our proposal for merging between repositories of
modules representing different major releases.

Application:
Versioning system (VS) – can stand for almost of any kind of revision control system capable
of the labelling and label moving
Bug tracking tool (BT) can be a tool which provides functionality of DFs or CRs records with
saving the status and comment possibility. Included access and user management suits more
as well as an extra data to store, the environment for instance.

(Note: roles are not exclusive to each other, perhaps only the groups)

9
 SOFTWARE CONFIGURATION MANAGEMENT

2.4 Predefined label tags

Basically there are two kinds of a label to consider. From the developer’s side it’s the test-
ready label (e.g. test-ready). Release manager takes care of the release label (e.g. v1.1.010).

2.5 Who is applying the label

The test-ready label is to be applied by a developer. In case of consistency fix the label can be
applied (moved) by the release manager.
The release label is to be applied by a release manager only. No developer is allowed to
interact with the release label(s) in anyway to preserve the consistent state.

2.6 Disposition of labels

The test-ready label is supposed to be moved because there will next - different revision
ready to be released, deployed and tested. At any new revision to be tested (deployed)
occurrence the label has to be moved.
In opposite, the release label is supposed to point to the same revision after has been finally
applied11 – it’s considered as a still or sticky label.

2.7 When to label

Label with the test-ready tag when a new (updated respectively) revision of a file is checked
in into VS (it’s the latest revision at a moment in fact; but this wouldn’t be necessarily
fulfilled in future - that’s the reason why we need a ‘checkpoint’, technically speaking a
label).
Label with ‘release’ tag when a new release is being built.
Refer to the “Defect tracking cycle diagram” below to check certain points to apply the label.
Applying any extra label12 (due to committed third party patch for instance) is (concurrently)
possible anytime.

2.8 When to label for a first time

During first phase of a development project there are just unit tests in the place and no
software releases, thus labelling is needed just later on.
The trigger to start labelling is the request of very first project version release, commonly
prior to first test phase, e.g. before FAT13. ‘Code freeze’14 time-line has to be introduced - at

10
technically wouldn’t be possible to store exactly in form of ‘v1.1.0’ for instance ; if so, common labels look
like ‘V1_ 1_0’ instead
11
Before finally applied the labeling methodology enforces once to move of the release label – the promotion to
the new release.
12
label could be for instance ‘PATCH_NO-0123456’
10
 SOFTWARE CONFIGURATION MANAGEMENT

this time-based checkpoint all software revisions are considered as test-ready, i.e. labelled
with test-ready label. For purposes of very first release all files with test-ready label are
labelled by the release tag.

Figure 2.1 Labelling has been applied for the very first time. There is no other release label
except initial-version and test-ready label, both pointing to the same revision of a
single file.

13
FAT ~ Factory Assembly Test; single module of system included to project is being tested without
interconnectivity nor interaction with other modules or systems; maximally the stubs are used
14
‘code freeze' is an expression for disallowance of another code commits to versioning system; a need for this
pops up when the first release related labels are going to be applied (test-ready and release label, e.g. v1.0.0);
because there was no test-ready revision so far, the one delivered at ‘code freeze’ time is the one
11
 SOFTWARE CONFIGURATION MANAGEMENT

2.9 The defect tracking cycle

The diagram represents the actions flow and shows when and what to label during
development (fixing, testing) project phase.

Figure 2.2 The defect tracking cycle [8]

Under
Discussion
Test
Commitee
Postponed No Defect
Defect is Defect is
closed closed

2. Assigned Under
Solution is Repair
Delivering the fix
Review of the defect identified
(Developer)
(Dev. Lead)
- Fill in changes made
- Name new, deleted
and changed files
- Label files in VS
Implementation of as test-ready
Review of the bug solution
Dev. Lead (Developers)
Test lead

5. Reopened
1. New 3.Repaired
Defect is 6. Solved
A defect is Defect is
reopened after Defect is
found corrected
testing closed

Closing defect
( Test Lead)
A defect is found during ( Dev. Lead)
test execution
(Test lead / Tester) Retesting of solution
(Test Lead / Tester)

Delivering the release

Reopening of bug (Configuration manager)
(Test lead / Tester)
4. To test
Defect is - Label files with release
delivered tag in VS
Not to the testing - Build package
Solved environment - Create release notes

12
 SOFTWARE CONFIGURATION MANAGEMENT

3 Preparing a release – deploying with

versioning system

3.1 Considerations for following example

Let’s consider the last released version has been v1.0.0 and new one to release is v1.1.0

Figure 3.1 Example of labels layout in VS repository on single file level. Two labels present,
pointing to different revisions.

3.2 The approach

Let the reader by guided through the actions to take. The focus is to keep small, clear and
isolated steps, i.e. to keep it as simple as possible.

3.2.1 Zeroth step – put new release label across repository

Put the label of new release onto each file which has got last (previous) release label and let it
point to the same revision of the single file, i.e. new release ~ last release.

13
 SOFTWARE CONFIGURATION MANAGEMENT

Figure 3.2 Status of single file after the zeroth step. Observe the new release label being
added and pointing to the same revision as the older one

3.2.2 Step one – extract list of files to be released from bug tracking tool
Obtain a list of updated (new) files which are filled into the BT for each specific bug-fix
(implemented CR respectively) and are supposed to be delivered (i.e. BT status of the bug is
‘repaired’15).
Run consistency checker on the repository against list of updated files to be released and
check the result, perform necessary fixes16 in VS and correct the list of files to be released if
required.

3.2.2.1 What could be a VS repository inconsistency

There are several potential possibilities:
• file is modified in VS, not listed in BT for any ‘repaired bug’
• file is modified in VS, not labelled as test-ready
• file is not modified in VS, listed as modified by a bug-fix in BT
• file is not checked in into VS, listed as modified by a bug-fix in BT
• file is not checked in into VS, has no label at all

3.2.3 Step two – move the new release label, i.e. promote the revision
Move recently placed new release label from old release revision to one labelled as test-ready,
i.e. make release label to point to the same revision of single file as the test-ready label does.
This is to be performed for each file from list of files to be released.

15
to check the defect statuses refer to the chapter 2.9 “The defect tracking cycle”
16
for example when the file is listed as to be promoted (with its new revision) to the new release, but the test-
ready label points still to the older revision - the developer probably has forgotten to apply the label after check-
in; the action to take is to move the test-ready label to proper revision
14
 SOFTWARE CONFIGURATION MANAGEMENT

Figure 3.3 Status of single file after the second step. See the new release label moved to other
revision, i.e. ‘v1.1.0’ label points now to the ‘test-ready’ labelled revision

3.2.3.1 What happens with not modified file

Not modified file is a file in VS repository without a new revision checked-in.
Figure 3.4 Status of single which has not been modified from last release. Head revision has
file.c the test-ready label as well as the last release label.

1.1 v1.0.0

1.2 test-ready

In the zeroth step there is applied a new release label on the same revision as previous release.

Figure 3.5 Status of a single - not modified - file in VS repository after the zeroth step. Head
revision has the test-ready label as well as the last release label – on top of it the
file.c label of new release is added, pointing to the same revision as previous one.

1.1 v1.0.0

1.2 test-ready

v1.1.0

Due to that there is no newer revision, this file is not listed in BT and could not appear as
inconsistency within VS repository check. No other step will affect this file and revision
labelled as new release will be delivered within new release (technically that is the same
revision as the one which has been released as the previous version). In this example: as
v1.0.0 has been released revision 1.2 and as v1.1.0 shall be released revision 1.2 as well.
If there in the future won’t be any modification of the file, any new label points to the same
revision as previous one, i.e. to the one still labelled as test-ready.
15
 SOFTWARE CONFIGURATION MANAGEMENT

Figure 3.6 status of a single file in VS repository after many new release labels have been
applied and the file is kept unmodified; i.e. all the labels point to the same revision
(in this example to the 1.2).
file.c

1.1 v1.0.0

1.2 test-ready

v1.1.0

v1.2.0

v1.3.0

v1.n.0

3.2.4 Step three – obtain all files of new release

Checkout or get all files supposed to be delivered within new release (or which are necessary
to create/compile this software release), i.e. obtain from VS all the files with the new release
label, e.g. with ‘v1.1.0’ label.

3.2.5 Step four – build the release package

Compile; do necessary steps like reconfigure installation configuration file and create new
release installation package as required by the project design or policy.

3.2.6 Step five – completion

Create release notes, mention all deployed bugs and change requests (included in the
package) and update the status of relevant bugs in bug-tracking tool. Finally store the
package in the agreed location together with the release notes and best create checksum file
for transfer and check purposes.

16
 SOFTWARE CONFIGURATION MANAGEMENT

4 Branching approach

4.1 General assumptions

When there is a need of development of a new major release, and current major release needs
to be continued with bug-fixing etc., the branching of the development, i.e. branching of the
source codes and configuration shall be introduced.
There are two way to follow on general. First one is widely accepted and used – the
branching within the same repository by using branching functionality of the versioning
system. As a benefit can be possibility to use built-in features for change within different
branches merging. The second way is to establish a separate repository copy for the new
major release. The benefit is prevented complexity of interactions with versioning system,
especially from the developer’s point of view. Disadvantage is no away of automatic branches
merging.
None of the solutions seem to be the perfect one from the first look. Natively I would choose
the regular and used inner branching. On other hand the developers are not always capable to
handle the operations with a versioning system. More complexity added on top looks to me as
contra productive.
To get more information and input the internal survey did happen within the circle of most
experienced project team members. Finally the decision took place, based on all the gathered
data.

4.2 Proposed solution

Establish new separate repository by checking in stable release version (best final, e.g. v1.0)
of the current software development line (obtained from existing repository).

4.2.1 When to create a separate repository

In the ideal case - the best timeline is when complete and tested – stable – current release is
ready.
In the common real case - if final major version of current release is not available and there is
a need to start with development of new release (e.g. due to limited time), the timeline is
presence of last stable minor release in highest development phase (with most of functionality
included).

17
 SOFTWARE CONFIGURATION MANAGEMENT

4.2.2 How to create a separate repository

The steps
1. checkout latest stable release from existing repository as a local working copy
2. establish new separate repository for new development line
3. check in obtained local working copy into new repository

Figure 4.1 New repository establishing procedure

file.c

1.1

1.2

1.3
timeline which triggers
creation of another
1.4 file.c development line
check out form
the old repository
v1.0.0 1.5 2.0 v2.0.0
and check in into
the new one

1.6 2.1

1.7 2,2
fixing

2.17

2.n v2.1.0

development

Extra possibility is just to directly clone the repository if the versioning systems allows
(basically to prevent any commits from being done during the operating). This may require
resetting of the revision identifiers to new sequence, e.g. from 1.22 to 2.1.

18
 SOFTWARE CONFIGURATION MANAGEMENT

4.2.3 How to work with separate repositories – the approach basis

Existing account of a developer is considered as development line 1 oriented. New account
for the developer shall be created and configured to connect to (work with) new repository
and considered as development line 2 oriented.
Separate database user and schema shall be created if needed for each developer with numeric
suffix for the new account (instance of software being developed)

19
 SOFTWARE CONFIGURATION MANAGEMENT

5 The tools

5.1 General assumptions

The versioning and release management approach as designed above, earlier in the document,
need the supporting tools to be in the place.
As required either a developer needs to be shielded from direct usage of any versioning
system commands with all necessary parameters to put the proper label. Probability of even
as simple issue as a mistyping is quite high. Experience shows as well that people aren’t
paying much attention to repeating tasks. And applying of test-ready label occurs in general
repeatedly and frequently.
The approach of the release build using versioning system requires a consistency check of VS
against BT. This is supposed to be handled by a separate tool.
The outcome is, that the minimum set of tools is
• tool to apply test-ready label on the file specified
• tool to check the consistency between versioning system and bug-tracking tool

The extra decision to make is which versioning system to use and build the tools for. The
things to consider are the scope of usage of the system nowadays, reliability, standardization,
commerciality, openness of the code and the repository database format, cross-platformness,
presence of the manuals and documentation and other minor values like any frond-end
presence etc.

5.2 Target versioning system

As the versioning system has been chosen The Concurrent Versions System, the well-known
CVS.
CVS is very spread, very used (commercial and free/open source projects as well including
many major project of this days); “CVS is a production quality system in wide use around the
world” [1], “CVS is the most popular version control system available today” [2]. It’s
reliable, robust, well documented; repository is plain text based and capable to be parsed by
external tools. CVS does support client-server architecture as well as user management, exists
in ports for many platforms even as binary package, moreover is open sourced.
Where CVS loses a credit is inability to version the folders itself and UN*X file system
symbolic links. That is possible to be handled with some workarounds, anyway.
20
 SOFTWARE CONFIGURATION MANAGEMENT

The other, CVS based versioning system, the Subversion alias SVN, solves these missing
things and has got all the great CVS functionality. On other hand – unfortunately – in the time
when the development of this project has started the SVN was not developed to the
production level, so it was excluded from the list of possible systems. However, future SVN
port of the tools should not be a too big deal.
Microsoft’s versioning product – the Microsoft® Visual SourceSafe™ - is not able to handle
label properly in manner as all the common versioning systems do; the repository is fully
operable only via graphical front-end (at least the command line tool is not properly
documented); repository is of proprietary binary format; real-life experience shows it’s
terribly slow while accessed concurrently, frequently even during single user access. The big
drawback is that, it’s not reliable: when a network problem occurs, it corrupts repository file
(not just last revision, but complete history for the file)! On top of all, there is an
announcement on Microsoft web site that this tool is supposed to be used just for small
teams/projects (any investigation if they did any progress with this system meanwhile has not
been done). All this brought this system out of the game of consideration.
Hints:
if one misses a possibility to use CVS as a versioning system while developing under
Microsoft® Visual Studio™ for instance on a Windows system he should be told about
existence of several free project of CVS and MS world IDE’s integration:
• JalindiIgloo (http://www.jalindi.com/igloo/) – MS® Visual Studio™
plug-in for CVS (complex and a bit buggy);
• ToitoiseCVS (GPL; http://www.tortoisecvs.org) - shell extension to work
with CVS by mouse “right-click” from Windows Explorer; very comfortable tool;
this way of work with a versioning system is more advisable than direct saving from
editor via plug-in;
experience shows that a developer pays more attention to interactions with a
versioning system while this is manager extra an IDE where he(she) develops in,
which is worth for the thing, indeed.
• WinCVS (http://www.wincvs.org) – A set of GUI front-ends for CVS written
in C++ and distributed under GPL, with native look-and-feel on Windows, Mac and
Unix/Linux thanks to the use of popular GUI frameworks like MFC, CJLibrary,
Metrowerks PowerPlant and gtk+ [5];
• CVS SCC proxy (http://www.pushok.com/soft_cvs.php) - the SCC API
plug-in which provides access from practically all Microsoft SCC enabled software to
general CVS repositories. The Microsoft SCC API is supported by: MS VC 5.0-7.0,
MS VB 5.0-7.0, MS .NET, MS FrontPage, MS DEV and other Microsoft
development tools. With the support of 3rd party tools this plug-in can be used by
Borland IDE's [6].

21
 SOFTWARE CONFIGURATION MANAGEMENT

5.3 Pre-implementation considerations

5.3.1 The repository access approach

The ways of accessing the versioning system repository while the CVS is chosen are either
directly parse the plain text based repository files or parse the output of CVS tools which will
access the repository.
The first way is possible, the format is well documented. The second possibility is doable as
well, CVS tools output format is claimed as kept preserved and capable to be parsed by
standard UN*X tools17.
Implementation will aim the first way – to parse the repository directly, taking the advantage
of the only prerequisite to the consistency check - just the repository copy and the tool
presence.

5.3.2 CVS repository database format - files

CVS is technically a management layer on top of RCS files – a CVS repository object is a
RCS file.
(Follows [4] quotation)

An RCS file's contents are described by the grammar below.

The text is free format: space, backspace, tab, newline, vertical tab, form feed, and carriage
return (collectively, white space) have no significance except in strings. However, white
space cannot appear within an id, num, or sym, and an RCS file must end with a newline.
Strings are enclosed by @. If a string contains a @, it must be doubled; otherwise, strings can
contain arbitrary binary data.
The meta syntax uses the following conventions: `|' (bar) separates alternatives; `{' and `}'
enclose optional phrases; `{' and `}*' enclose phrases that can be repeated zero or more times;
`{' and '}+' enclose phrases that must appear at least once and can be repeated; Terminal
symbols are in boldface; nonterminal symbols are in italics.
rcstext ::= admin {delta}* desc {deltatext}*

admin ::= head {num};

{ branch {num}; }
access {id}*;
symbols {sym : num}*;
locks {id : num}*; {strict ;}
{ comment {string}; }
{ expand {string}; }
{ newphrase }*

17
[f,e]grep, [s]ed, awk for instance
22
 SOFTWARE CONFIGURATION MANAGEMENT

delta ::= num

date num;
author id;
state {id};
branches {num}*;
next {num};
{ newphrase }*

desc ::= desc string

deltatext ::= num

log string
{ newphrase }*
text string

num ::= {digit | .}+

digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

id ::= {num} idchar {idchar | num}*

sym ::= {digit}* idchar {idchar | digit}*

idchar ::= any visible graphic character except special

special ::= $ | , | . | : | ; | @

string ::= @{any character, with @ doubled}*@

newphrase ::= id word* ;

word ::= id | num | string | :

Identifiers are case sensitive. Keywords are in lower case only. The sets of keywords and
identifiers can overlap. In most environments RCS uses the ISO 8859/1 encoding: visible
graphic characters are codes 041-176 and 240-377, and white space characters are codes 010-
015 and 040.
Dates, which appear after the date keyword, are of the form Y.mm.dd.hh. mm.ss, where Y is
the year, mm the month (01-12), dd the day (01-31), hh the hour (00-23), mm the minute (00-
59), and ss the second (00-60). Y contains just the last two digits of the year for years from
1900 through 1999, and all the digits of years thereafter. Dates use the Gregorian calendar;
times use UTC.
The newphrase productions in the grammar are reserved for future extensions to the format of
RCS files. No newphrase will begin with any keyword already in use.
(end of [4] quotation)

23
 SOFTWARE CONFIGURATION MANAGEMENT

Each versioned object has the history file within repository, having the same file name as
corresponding object with ‘,v' appended to the end.

5.3.3 CVS repository database format - folders

CVS repository contains basically folders of following kind:
• administrative files location (<repo_path>/CVSROOT)
• module folders (<repo_path>/<module_name>)
18
• “trash” folder (<repo_path>/<any_folder>/Attic)

CVSROOT as well as any Attic folder wouldn’t be a subject to consistency check19; i.e.
should be skipped automatically.

5.3.4 CVS repository database - location

The CVS repository is a structure of folders and files on a file system accessible for its native
tools. Repository can reside on a local file system or remotely on different host running in
server mode (remote control over SSH possible either) on other hand.
CVSROOT is a name or alias (usually set up environmental variable of the same name)
specifying the repository location20.

5.3.5 CVS local checked out copy admin structures

During the check-out of a local working copy of a module, local CVS administrative
structures are being created in each folder; the subfolder name is always “CVS”, all admin
files are created into that.
The interesting data stored there is the path to CVS repository21. This is one of the possible
sources where the tool can obtain the repository path, alias CVSROOT.

18
used to store the objects removed from active project and kept for history data repository lookup (retrieval an
old project release for instance)
19
there is no relevance between internal CVS data and subject of the consistency check; in other words there is no
reference between CVS internal data and BT data
20
e.g. /usr/local/cvsrepos
21
where the local copy has been checked out from
24
 SOFTWARE CONFIGURATION MANAGEMENT

5.3.6 The programming language

The language to develop the thing in shall be determined by the major functionality and tasks
required to be done by the tool. For a first is would get the data by parsing the repository
database, secondly with lower severity a comparisons are to be done. No special real time
functionality needed.
Best for text data parsing are scripting languages. Well known PHP suits best for a web based
development, Perl is pretty fine for the purpose, but the code might not be as nicely readable
as expected, but more important is that Perl is not installed on a regular UN*X system per
default, hence it increases the tool prerequisites.
To keep it simple and straight forward to implement and to minimize the prerequisites to the
system, the UN*X shell scripting is the solution, with employing (just only) the standard
UN*X tools, the AWK in major. Such a solution is fully capable to parse the input data as
well as to do the rest of required functionality. For efficiency the GNU tools are to be used,
but with the functionality in line with POSSIX norm.

Résumé: CVS is the versioning platform; OS UN*X; application code: BASH based script
including AWK code, employing standard UN*X tools, the POSSIX based functionality.

5.4 The implementation

The tools are to be implemented on UN*X system platform. Thus naming convention for
them shall follow the UN*X standard, the parameter names shall mimics the convention of
CVS.
The tools resides in two working areas
• The Developer space
• The Release Manager space

The first one makes a test-ready label to point to the last checked in revision of a file; it has
name “mklabel”.
The parameter is to be only the file name which the label should be put (make) on; the
CVSROOT data is taken automatically from local control folder or eventually from shell
environment (aim is to prevent the user from a need to specify the obvious information; if the
control folder isn’t present the check-in is not possible anyway).
The second one – the checker of CVS consistency against data from BT – has got name
“cvs_rcheck”. The “r” in the name follows convention of CVS: for an action upon repository
files directly22 it has “r” in the parameter name23; the cvs_rcheck is supposed to perform only
repository direct action.

22
so called “remote” action
23
for instance rlog, rtag
25
 SOFTWARE CONFIGURATION MANAGEMENT

The inputs are to be specified from command line as positional parameters. The naming
convention follows the one of CVS.
It tries to retrieve the needed data locally if possible, complains when missing. The command
line parameter overrides the data found locally. For the parameters list is the best to refer to
(usage) help message of the script.

Figure 5.1 Help message of the script

USAGE INFO:

cvs_rcheck <parameter> <value>

Supported parameters list:

-d CVS repository path (e.g. /usr/local/cvsrepos)
default: TEST_READY

Input source priority (higher no. ~ lower prio.):

1. explicitly specified value of the "-d" parameter
2. ./CVS/Root file content
3. exported CVSROOT environmental variable

-r * CVS 'Release' label/tag (e.g. R1_10_2)

default: n/a
-t CVS 'Test-ready' label/tag
default: TEST_READY
-l * list of files to be promoted
default: n/a
-x list of modules to exclude from the checking
default: n/a
-o output log directory
default: /tmp

* - mandatory

To print out this usage message

-[?|u|U|h|H] --[help|usage]

5.4.1 Common functionality

Both the tools need - due to the nature of their major functionality or necessary checks – to
implement functionality to compare revisions.

26
 SOFTWARE CONFIGURATION MANAGEMENT

The revisions are represented in textual form as digits separated by the dot (“.”) character.
While branching isn’t used, all the revisions are to be of the form X.Y, where both X and Y
fit pattern [0-9]+ (digit of at least one occurrence; e.g. 1.24). Branched revisions (form of
X.Y.Z.W, i.e. containing more “dots") are not supported in this version. Only one branch
revision taken into the consideration is the one created during very first import into the
repository after its setup. The import creates branch; while the repository is empty so far it
makes revision to appear on an import branch as well as on the main regular branch. First
regular checked in revision is 1.1 and first branch revision is 1.1.1.1. They are technically the
same, but the check if a case hits this scenario is implemented.
Basically there is one function, AWK based, performing revisions comparison and called
compare_revisions. Parameters to be passed are two strings representing revisions to
compare. Result is returned is the exit code (follows UN*X scripting conventions). Exit
codes:
# exit code(s): (i.e. which one is bigger;)
# 0: $1 = $2 (no one)
# 1: $1 > $2 (the first one)
# 2: $1 < $2 (the second one)

Example of function call:

compare_revisions $REV_TST $REV_REL;
which for instance could be expanded to
compare_revisions 1.12 1.9;
and the result code in such a case is
1

or special case
compare_revisions 1.1 1.1.1.1;
if fits to “first-import“ schema it returns
0

5.4.2 The developer space tool – mklabel

This tool is supposed to be as simple as possible to make developer’s life easier. Only
parameter which needs to be passed to the tool is the name of file where the label is about to
be applied to.
The rest of the necessary data is gathered by native CVS command tool used within the script
(technically from the UN*X shell environment or administrative CVS subfolder).

27
 SOFTWARE CONFIGURATION MANAGEMENT

Technically the mklabel tool is a wrapper around native CVS command “cvs”; mklabel does
all the checks before the tag is applied to avoid situation that the test-ready label points to
incorrect revision.
The circumstances under which the user is able to successfully execute the tool are quite
strict. For a first the current directory is required to be the one where the to-be-labelled file
located is, for a second only single file can be specified at once, moreover is there is detected
any stickiness on the local copy of the file the user is announced and needs to confirm
explicitly continuation of the operation – that all shall prevent the developer from usage of
the tool in recursive manner, which can potentially lead to labelling of more files than the
ones supposed to be test-ready; or accidentally label wrong revision, respectively. Aim is to
force the developer to do simple and clear steps during the label applying procedure.

Figure 5.2 Usage syntax of mklabel

mklabel ./<file_name>

e.g.:
mklabel ./http_lib.c

5.4.3 The release-manager space tool – cvs_rcheck

The tool implements basic features as well as a set of extended ones to be able to check status
of each single file in the repository and compare gathered information against data from bug-
tracking tool to discover any inconsistencies.
Basic features:
• get CVSROOT to be aware of CVS repository location; firstly is tries to use UN*X
shell environmental variable $CVSROOT, if not found the lookup is done in the local
CVS administrative folder to the file which stores the data, i.e. to the ./CVS/Root;
all this – as mentioned already in this chapter – can be overridden by a command line
parameter, the “–d”
• get CVS status from repository for a file (to retrieve list of labels and corresponding
revision numbers)
• get CVS log of the file (to gather the data to distinguish between the revision in the
explicit way; basically needed to verify the scenario of identical revision 1.1 and
1.1.1.1)
• from retrieved data extract revision number related to the specific label (to the test-
ready and to release label either; release label is one of the mandatory parameters to
be specified from the command line)

28
 SOFTWARE CONFIGURATION MANAGEMENT

• get list of files to be promoted to be included to the new release (plain text based,
each file name on a separate line; UNIX newlines /0x0A/ are a must)
• to output and log the results for each file detected within the repository; prefix of
output and log files can be modified by the input parameter, the “–o”

Extended features:
• to be able to skip a set of repository modules during the check; the set is represented
as a plain text file with module name on a single line (UNIX newline characters are
required), comments are supported and defined as a line(s) beginning with the sharp
(“#”) character;
the file name is to be passed to the tool as an extra input parameter, the “–x” (derived
from “list to exclude”)
• map the reported and logged file names to the path format relative to potential check-
out point in order to use the script output data directly (i.e. simply copy&paste);
mapping data is gathered directly from repository control and configuration data (the
$CVSROOT/CVSROOT/modules file)

The first extended feature has not to be necessarily used, but on other hand becomes very
helpful when the repository stores several different sub-projects (as modules) and the release
manager is going to check the consistency (prepare new release in other words) only for a
specific sub-set, specific list of modules. In such a case it suits best to exclude not needed
modules from check to avoid their content as inconsistency in check result.
The second extended feature, so called module mapping, automatically takes the data from

Figure 5.3 List of modules to exclude (file content)

cvs_rcheck-module_exclude_list.txt:
# -- main application
#server_module
server_module_lib
# -- migration team
migrator
migrator_ddl

configuration file mentioned above and parses it to get the settings to be able map the path
properly. If there is no module mapping configured in the repository, the feature is silently
skipped. Having output in a convenient format increases efficiency of release manager when
there is a need of manual intervention to the repository (even simple check).

29
 SOFTWARE CONFIGURATION MANAGEMENT

Figure 5.4 Module mapping schema instance

CVSROOT: /usr/local/cvs_repo/
Module: server_lib
CVS module configuration: server_lib ~ server/lib
(which says that module ‘server_lib’ should be checked out to
‘server/lib’ folder relative to checkout point)
Example of full path in repository module:
/usr/local/cvs_repo/server_lib/http_lib.c
Example of full path in checked out local copy:
/home/marek/devel/server/lib/http_lib.c
(while checkout point is ~/devel/)
Mapped path of http_lib.c:
server/lib/http_lib.c

Both module check exclusion and module mapping are designed and implemented to be
performed in the way of a single sed script (script of regular expressions in format
interpretable by UN*X tool “sed”). The script is compiled during initialisation phase of the
tool and handles all the modules at once.
There are two major outputs of the tool – standard output and file logging.
To the standard output is printed first summary information before the check run begins and
during execution there is information of processed file and its status from the check as well as
the found revision numbers; filename format is relative to checkout point (module mapping
takes action).
The file logging splits itself into the three channels: log file, csv24 file and xls25 file
• the log file entry consists form file status, revision numbers, mapped file path and
absolute path repository within repository; ends up with the processing time statistics
(start time, end time)
• the csv file entry is the same as log entry except absolute path, fields separated by
semicolons (“;”); purpose is to be processed if needed by external tool
• the xls file mimics csv file and extends features by adding colour highlighting to rows
according the status of the file
ok, file status is new and consistent – green background
ok, file status is unmodified and consistent –- default background kept
not ok, file status inconsistent – red background
the format of the xls is not binary one; Microsoft has introduced an extra format of
xls files since office version 9: basically a kind of xml + html + css based format (one

24
plain text file with comma separated values on a line
25
MS© Excel Sheet.
30
 SOFTWARE CONFIGURATION MANAGEMENT

can call it xhtml format); this allows to generate an xls file instance directly from a
UN*X shell script with taking an advantage of plain text output to a file.
First html container for instance:
<html xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns="http://www.w3.org/TR/REC-html40">

The checker does evaluation of file status in repository and compiles a status string of 5
characters from terminals set of {+,-,#}. The last terminal can occur only at the 5th position.
In general “+” means condition’s accomplished, “-“ represents failed condition and finally
“#” fulfils and condition occurrence.
The first check detects presence of test-ready label; the second one detects the release label
presence; the third check (informative): is there newer revision then the test-ready one?; the
fourth check: is test-ready revision higher than, or equal to the head revision?; finally the fifth
check: if a file name appears on the list of files to be promoted?
The fifth check is a special one with three statuses depending on the forth check result:
• 4th check positive: the file is supposed to be in the list of file to be promoted and if is,
check goes to ok -> “+”
• 4th check negative: the file is not supposed to be promoted to the new release, thus if
it’s not listed on the list of to-be-promoted files it’s ok -> “+”; but if despite that
occurs on the list, something extra went wrong26 -> “#”

26
typically the developer mentioned the file as test-ready in BT, but did not check the file in into the VS
31
 SOFTWARE CONFIGURATION MANAGEMENT

Figure 5.5 Usage syntax of cvs_rcheck

Full:
cvs_rcheck -d <cvs_repo_path> \
-r <release_label> \
-t <test-ready_tag> \
-l <list_of_files_to_be_promoted> \
-x <list_of_modules_to_exclude_from_checking> \
-o <output_log_directory>
e.g.:
cvs_rcheck -d /usr/local/cvs_repo/ \
-r R_1_10_3 \
-t TEST_READY \
-l R_1_10_3-BT_list.txt \
-x cvs_rcheck_module_exclude_list.txt \
-o /home/marek/releases/R_1_10_3/
Minimally:
cvs_rcheck -r R_1_10_3 \
-l R_1_10_3-BT_list.txt

32
 SOFTWARE CONFIGURATION MANAGEMENT

6 The conclusion

The thesis provided a reader with the terminology overview as well as introduction to the
area, including example of inappropriate versioning system usage – to get an image of the
problems.
The project brought the specific solution – structured way described the approach of
employing versioning system for the purposes of the release management, which succeeds in
the mandatory prerequisites creation for successful release build, deployment and project
internal/external delivery.
The details level went to extend that just commands of a particular versioning system could
deepen the information provided.
The tools implemented provide the claimed functionality. Moreover, the tools developed by
me within this master’s thesis project (as well as the set up approach) are being used now
within one of the teams of the project which I joint in the year 2005 to support smooth and
transparent deployment process (frequently into a testing environment). In the time when I
rolled off the other teams were about to establish this approach as the team’s approach due to
issues related to the deployment of a release (issues were caused by missing or inappropriate
release management, software configuration management respectively). No issues
encountered so far. This could be considered as proof of concept as well as of correctness of
design and implementation.
Possible improvements are for instance to tune the parameters and usage of frequently
utilized UN*X command during the run, i.e. sed or grep. Extra focus can be put on
removal of temporary files usage in appeared scope. I’ve started the implementation on the
SUN Solaris 5.8 system, which mounts /tmp into the memory, thus no hard disk access
slowdown. Linux uses regular hard disk area, so the disk access speed takes place.
Fortunately the time of execution was not critical so far, maximum time experiences has been
around 25 minutes for repository sized at 600MB, containing binary files as well. The disk
was SCSI one, the machine Sun SunFire 440.

33
 SOFTWARE CONFIGURATION MANAGEMENT

7 Literature and resources

[1] DPRICE, CVS,

http://www.nongnu.org/cvs/ (May, 2006)
[2] About CVS,
http://ximbiot.com/cvs/ (May, 2006)
[3] Price, Derek R., CVS v1.11.21 On-Line Manual,
http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs.html, (May, 2006)
[4] Tichy, Walter F., Purdue University, West Lafayette, IN, 47907. Manual Page
Revision: 5.6; Release Date: 1995/06/05. Copyright © 1982, 1988, 1989 Walter F.
Tichy. Copyright © 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert.
The RCS Manual Page on-line,
http://www.die.net/doc/linux/man/man5/rcsfile.5.html, (May, 2006)
[5] CvsGui features, WinCVS home web site,
http://www.wincvs.org/ (May, 2006)
[6] CVS & SCC, CVS SCC proxy plug-in,
http://www.pushok.com/soft_cvs_proxy.php (May, 2006)
[7] Sobell, Mark G., Linux – Praktický průvodce
Computer Press 1999, ISBN 80-7226-190-8
[8] Mehmet, Emre Can, Factory Assembly Test Execution,
2005

34
 SOFTWARE CONFIGURATION MANAGEMENT

A Appendix

a. The cvs_rcheck script output

Figure A.1 The csv file content

STATUS;HEAD_REV;TO_TEST_REV;TO_RELEASE_REV;FILE_NAME
+++-+;1.1;1.1.1.1;1.1.1.1;server/setup/README
+++-#;1.1;1.1.1.1;1.1.1.1;server/setup/LICENCE
+++++;1.2;1.2;1.1;server/setup/setup.conf
++++-;1.3;1.3;1.2;server/setup/setup.sh
----+;1.2;n/a;n/a;DP/test-input_params.sh
----+;1.2;n/a;n/a;DP/test-module_mapping.sh
----+;1.3;n/a;n/a;DP/mklabel
----+;1.6;n/a;n/a;DP/cvs_rcheck
----+;1.1;n/a;n/a;DP/R1_10_3-BT_list.txt
----+;1.1;n/a;n/a;DP/cvs_rcheck-module_exclude_list.txt
----+;1.1;n/a;n/a;DP/test-module_excluding.sh

Figure A.2 The xls file content

STATUS HEAD TEST RELEASE FILE NAME
+++-+ 1.1 1.1.1.1 1.1.1.1 server/setup/README
+++-# 1.1 1.1.1.1 1.1.1.1 server/setup/LICENCE
+++++ 1.2 1.2 1.1 server/setup/setup.conf
++++- 1.3 1.3 1.2 server/setup/setup.sh
----+ 1.2 n/a n/a DP/test-input_params.sh
----+ 1.2 n/a n/a DP/test-module_mapping.sh
----+ 1.6 n/a n/a DP/mklabel
----+ 1.6 n/a n/a DP/cvs_rcheck
----+ 1.1 n/a n/a DP/MLO_BE_V1_10_6_0-list.txt
----+ 1.2 n/a n/a DP/cvs_rcheck-module_exclude_list.txt
----+ 1.2 n/a n/a DP/test-module_excluding.sh

The situation shown is the README file hasn’t been changed nor listed on the list of files to
be promoted (list) [ok]; LICENCE file hasn’t been updated but mentioned on the list [nok];
file setup.conf has been modified in VS and present on the listlisted [ok]; setup.sh modified
but not listed [nok]; all other files where never released as any release even never label as
test-ready

35
 SOFTWARE CONFIGURATION MANAGEMENT

b. An example of history graph of a file in VS repository

Figure A.3 Graphical CVS log

Figure shows an example of cvs graphical log representing all lebels applied in past, i.e.
which revision has been released as which release.
Example screenshot is taken from [5].

36
 SOFTWARE CONFIGURATION MANAGEMENT

c. The mklabel in action

Figure A.4 Saved output from the command shell while working with mklabel tool

[marek@agaue DP]$ ll
drwxrwxr-x 2 marek marek 4096 May 15 21:09 CVS
-rwxrwxr-x 1 marek marek 23847 May 15 20:43 cvs_rcheck
-rw-rw-r-- 1 marek marek 125 Apr 20 01:53 cvs_rcheck-
module_exclude_list.txt
-rwxrwxr-x 1 marek marek 8335 May 15 20:49 mklabel
-rw-rw-r-- 1 marek marek 9 Nov 17 00:06 V1_10_6_0-BT_list.txt
-rwxr--r-- 1 marek marek 2244 Apr 13 00:24 test-input_params.sh
-rwxr--r-- 1 marek marek 1260 Apr 20 00:50 test-module_excluding.sh
-rwxr--r-- 1 marek marek 1777 Apr 12 23:39 test-module_mapping.sh
-rwxrwxr-x 1 marek marek 953 May 15 21:04 test.sh
[marek@agaue DP]$ cvs log test.sh
RCS file: /usr/local/cvs_repo/DP/test.sh,v
Working file: test.sh
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
----------------------------
revision 1.1
date: 2005/11/22 23:49:24; author: marek; state: Exp;
First checkin - a tool to test the approach(es), currently gawk vs
UNIX awk test and getting the module mapping test
=====================================================================
[marek@agaue DP]$ ./mklabel test.sh
mklabel (developer space)
Head revision: 1.1
Repository revision: 1.1
Sticky revision: (none)

37
 SOFTWARE CONFIGURATION MANAGEMENT
Tagging...
T test.sh
File [test.sh] successfully labeled with tag TEST_READY
[marek@agaue DP]$ cvs log test.sh
RCS file: /usr/local/cvs_repo/DP/test.sh,v
Working file: test.sh
head: 1.1
branch:
locks: strict
access list:
symbolic names:
TEST_READY: 1.1
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
----------------------------
revision 1.1
date: 2005/11/22 23:49:24; author: marek; state: Exp;
First checkin - a tool to test the approach(es), currently gawk vs
UNIX awk test and getting the module mapping test
=====================================================================
[marek@agaue DP]$ echo "" >> test.sh
[marek@agaue DP]$ cvs commit -m "dummy extra revision" test.sh
Checking in test.sh;
/usr/local/cvs_repo/DP/test.sh,v <-- test.sh
new revision: 1.2; previous revision: 1.1
done
[marek@agaue DP]$ cvs log test.sh
RCS file: /usr/local/cvs_repo/DP/test.sh,v
Working file: test.sh
head: 1.2
branch:
locks: strict
access list:
symbolic names:
TEST_READY: 1.1
keyword substitution: kv
total revisions: 2; selected revisions: 2

38
 SOFTWARE CONFIGURATION MANAGEMENT
description:
----------------------------
revision 1.2
date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0
dummy extra revision
----------------------------
revision 1.1
date: 2005/11/22 23:49:24; author: marek; state: Exp;
First checkin - a tool to test the approach(es), currently gawk vs
UNIX awk test and getting the module mapping test
=====================================================================
[marek@agaue DP]$ ./mklabel test.sh
mklabel (developer space)
Head revision: 1.2
Repository revision: 1.2
Sticky revision: (none)
Tagging...
T test.sh
File [test.sh] successfully labeled with tag TEST_READY
[marek@agaue DP]$ cvs log test.sh
RCS file: /usr/local/cvs_repo/DP/test.sh,v
Working file: test.sh
head: 1.2
branch:
locks: strict
access list:
symbolic names:
TEST_READY: 1.2
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.2
date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0
dummy extra revision
----------------------------
revision 1.1
date: 2005/11/22 23:49:24; author: marek; state: Exp;

39
 SOFTWARE CONFIGURATION MANAGEMENT
First checkin - a tool to test the approach(es), currently gawk vs
UNIX awk test and getting the module mapping test
=====================================================================
[marek@agaue DP]$ cvs update -r 1.1 test.sh
U test.sh
[marek@agaue DP]$ cvs log test.sh
RCS file: /usr/local/cvs_repo/DP/test.sh,v
Working file: test.sh
head: 1.2
branch:
locks: strict
access list:
symbolic names:
TEST_READY: 1.2
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.2
date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0
dummy extra revision
----------------------------
revision 1.1
date: 2005/11/22 23:49:24; author: marek; state: Exp;
First checkin - a tool to test the approach(es), currently gawk vs
UNIX awk test and getting the module mapping test
=====================================================================
[marek@agaue DP]$ ./mklabel test.sh
mklabel (developer space)
Head revision: 1.2
Repository revision: 1.1
Sticky revision: 1.1
You are going to tag not the latest revision of file [test.sh].
Latest: 1.2/Current: 1.1
Are you sure? [y/n]
y
Tagging...
T test.sh
File [test.sh] successfully labeled with tag TEST_READY

40
 SOFTWARE CONFIGURATION MANAGEMENT
[marek@agaue DP]$ cvs log test.sh
RCS file: /usr/local/cvs_repo/DP/test.sh,v
Working file: test.sh
head: 1.2
branch:
locks: strict
access list:
symbolic names:
TEST_READY: 1.1
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.2
date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0
dummy extra revision
----------------------------
revision 1.1
date: 2005/11/22 23:49:24; author: marek; state: Exp;
First checkin - a tool to test the approach(es), currently gawk vs
UNIX awk test and getting the module mapping test
=====================================================================
[marek@agaue DP]$ cvs tag -d TEST_READY test.sh
D test.sh
[marek@agaue DP]$ cvs admin -o 1.2 test.sh
RCS file: /usr/local/cvs_repo/DP/test.sh,v
deleting revision 1.2
done
[marek@agaue DP]$ cvs log test.sh
RCS file: /usr/local/cvs_repo/DP/test.sh,v
Working file: test.sh
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1

41
 SOFTWARE CONFIGURATION MANAGEMENT
description:
----------------------------
revision 1.1
date: 2005/11/22 23:49:24; author: marek; state: Exp;
First checkin - a tool to test the approach(es), currently gawk vs
UNIX awk test and getting the module mapping test
=====================================================================

42