SCM Software Configuration Management

(1)

MASARYK UNIVERSITY

FACULTY OF INFORMATICS

Master’s Thesis

SCM – Software Configuration Management

(2)

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.

(3)

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.

(4)

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.

(5)

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

(6)

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.

(7)

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.

(10)

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

(11)

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.

(12)

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

(13)

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

(14)

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

(15)

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.

(16)

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

(17)

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

(18)

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

(19)

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.

(20)

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

(21)

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.

(22)

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

(23)

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

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.

(24)

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

(25)

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.

(26)

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.

(27)

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)

(28)

20

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.

(29)

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

(30)

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

(31)

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

(32)

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

(33)

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

(34)

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]

(35)

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

(36)

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

(37)

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

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

(38)

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

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:

(39)

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 -> “#”

(40)

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 \

(41)

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.

(42)

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

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,

(43)

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

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

(44)

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

(45)

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

(46)

38 Tagging...

T test.sh

File [test.sh] successfully labeled with tag TEST_READY [marek@agaue DP]$ cvs log test.sh

head: 1.1 branch: locks: strict access list: symbolic names: TEST_READY: 1.1 keyword substitution: kv

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

(47)

description:

--- revision 1.2

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

--- revision 1.1

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

--- revision 1.2

(48)

40 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

--- revision 1.2

--- revision 1.1

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

(49)

--- 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 RCS file: /usr/local/cvs_repo/DP/test.sh,v deleting revision 1.2

done

head: 1.1 branch:

(50)

42 description:

--- revision 1.1

SCM Software Configuration Management

MASARYK UNIVERSITY

FACULTY OF INFORMATICS

SCM – Software Configuration Management

Declaration

Acknowledgements

Syllabus

Keywords

Preface

Table of contents

1

Introduction

1.1

Overview

1.2

Terminology

1.3

Common inappropriate usage of a versioning system

2

Source code versioning approach

2.1

General assumptions

2.2

Main goals overview

2.3

Actors

2.4

Predefined label tags

2.5

Who is applying the label

2.6

Disposition of labels

2.7

When to label

2.8

When to label for a first time

2.9

The defect tracking cycle

3

Preparing a release – deploying with

versioning system

3.1

Considerations for following example

3.2

The approach

4

Branching approach

4.1

General assumptions

4.2

Proposed solution

5

The tools

5.1

General assumptions

5.2

Target versioning system

5.3

Pre-implementation considerations

5.4

The implementation

6

The conclusion

7

Literature and resources

A

Appendix

a.

The cvs_rcheck script output

b.

An example of history graph of a file in VS repository

c.

The mklabel in action