scm - software configuration management - is muni

MASARYK UNIVERSITY

FACULTY OF INFORMATICS

Master’s Thesis

SCM – Software Configuration Management

Marek Bokes

2006

ii

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

iii

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.

iv

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.

v

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

vi

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.

vii

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

viii

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

SOFTWARE CONFIGURATION MANAGEMENT

1

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.


2

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.)


3

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)

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

Figure 1.1 Shows growth of single file revisions number


4

1.1

1.2

1.3

1.4

file1.c

1.1

1.2

1.3

file2.c

1.1

1.2

1.3

1.4

file3.c

1.1

1.2

1.3

1.4

file4.c

1.1

file5.c

1.5

1.6

1.5

LABEL

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


5

1.1

1.2

1.3

1.4

file1.c

1.1

1.2

1.3

file2.c

1.1

1.2

1.3

1.4

file3.c

1.1

1.2

1.3

1.4

file4.c

1.1

file5.c

1.5

1.6

1.5

have a look at

this ‘level’

LABEL

version

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.4 Shows how the label puts different revisions of different files virtually to one

line. The line represents one specific release.

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

ready.


6

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


7

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.


8

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


9

• 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)


10

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’


11

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.

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

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.


12

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]

2. Assigned

Solution is

identified

3.Repaired

Defect is

corrected

4. To test

Defect is

delivered

to the testing

environment

6. Solved

Defect is

closed

5. Reopened

Defect is

reopened after

testing

Reopening of bug

(Test lead / Tester)

Review of the defect

(Dev. Lead)

Implementation of

solution

(Developers)

Delivering the release

(Configuration manager)

- Label files with release

tag in VS

- Build package

- Create release notes

Closing defect

( Test Lead)

( Dev. Lead)

1. New

A defect is

found

A defect is found during

test execution

(Test lead / Tester)

Review of the bug

Dev. Lead

Test lead

Retesting of solution

(Test Lead / Tester)

Under

Repair

Not

Solved

Under

Discussion

Test

Commitee

Postponed

Defect is

closed

No Defect

Defect is

closed

Delivering the fix

(Developer)

- Fill in changes made

- Name new, deleted

and changed files

- Label files in VS

as test-ready


13

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

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.

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

pointing to different revisions.


14

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

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


15

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.

1.1

1.2

file.c

test-ready

v1.0.0

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

1.1

1.2

file.c

test-ready

v1.0.0

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.

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

Figure 3.4 Status of single which has not been modified from last release. Head revision has

the test-ready label as well as the last release label.

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

label of new release is added, pointing to the same revision as previous one.


16

1.1

1.2

file.c

test-ready

v1.0.0

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.

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).


17

4 Branching approach


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).


18

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

1.1

1.2

1.3

1.4

file.c

1.5

file.c

2.0

1.6

1.7

2.1

2,2

timeline which triggers

creation of another

development line

fixing

2.17

2.n

development

check out form

the old repository

and check in into

the new one

v1.0.0 v2.0.0

v2.1.0

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.


19

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)


20

5 The tools


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.


21

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].


22

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


23

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)


24

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>)

• “trash” folder18 (<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


25

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


26

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

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.

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]


27

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).


28

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.

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)

Figure 5.2 Usage syntax of mklabel

mklabel ./<file_name>

e.g.:

mklabel ./http_lib.c


29

• 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

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).

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


30

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.

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


31

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


32

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


33

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.


34

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


35

A Appendix

a. The cvs_rcheck script output

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

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

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

Figure A.2 The xls file content


36

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

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].

Figure A.3 Graphical CVS log


37

c. The mklabel in action

[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)

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


38

Tagging...

T test.sh

File [test.sh] successfully labeled with tag TEST_READY




head: 1.1

branch:

locks: strict

access list:

symbolic names:

TEST_READY: 1.1



description:

----------------------------

revision 1.1



=====================================================================

[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




head: 1.2

branch:

locks: strict

access list:

symbolic names:

TEST_READY: 1.1




39

description:

----------------------------

revision 1.2

date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0

dummy extra revision

----------------------------

revision 1.1



=====================================================================



Head revision: 1.2


Sticky revision: (none)

Tagging...

T test.sh





head: 1.2

branch:

locks: strict

access list:

symbolic names:

TEST_READY: 1.2



description:

----------------------------

revision 1.2



----------------------------

revision 1.1



40


=====================================================================

[marek@agaue DP]$ cvs update -r 1.1 test.sh

U test.sh




head: 1.2

branch:

locks: strict

access list:

symbolic names:

TEST_READY: 1.2



description:

----------------------------

revision 1.2



----------------------------

revision 1.1



=====================================================================



Head revision: 1.2


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



41




head: 1.2

branch:

locks: strict

access list:

symbolic names:

TEST_READY: 1.1



description:

----------------------------

revision 1.2



----------------------------

revision 1.1



=====================================================================

[marek@agaue DP]$ cvs tag -d TEST_READY test.sh

D test.sh

[marek@agaue DP]$ cvs admin -o 1.2 test.sh


deleting revision 1.2

done




head: 1.1

branch:

locks: strict

access list:

symbolic names:




42

description:

----------------------------

revision 1.1



=====================================================================

scm - software configuration management - is muni

Documents