MASARYK UNIVERSITY FACULTY OF INFORMATICS
Master’s Thesis SCM – Software Configuration Management Marek Bokes 2006
Declaration
I declare that this thesis is the original author’s work; done independently by myself. All the data, information and resources as well as publications used within the work are quoted with a qualified reference to the origin. Supervisor: Mgr. Miroslav Kubásek
ii
Acknowledgements
This way I would like to thank to the thesis supervisor, to Mgr. Miroslav Kubásek, for all the guidelines and willingness. Furthermore, my thanks goes to Udo Weber as well as to Hendrik Hempel for the consultations regarding release management.
iii
Syllabus
Source code and configuration versioning itself as well as labelling technique is wide spread in IT world of software development. The have got full control over release management and consequently over deployment process it requires the proper and suitable usage of a versioning system. Only with full control and appropriate usage a release management can’t became a serious bottleneck of the delivery process. As a solution this master’s thesis project brings comprehensive package – a set of defined approach of software versioning and release management besides cooperation with a bug tracking system on one hand, and tools to follow this approach up, i.e. enable this to happen in praxis, on the other hand. Tools to work with versioning system are provided for both developer and configuration (release) manager for specific platform and versioning system.
iv
Keywords
Software Configuration Management, Source Code Versioning, Software Deployment Approach, Software Release Approach, CVS, Bug Tracking System (Tool), Software Release, Tag, Label, Revision, Consistency Checking
v
Preface
"Source Control is as much a way of thinking about software development as it is a tool. It can facilitate parallel development and enable developmental isolation, but it can ensure neither. Only by establishing and following through on a strategy can a team use Source Control to its fullest potential " The Microsoft Corporation The managed way of source code versioning (also known as source code revision control) is to be assumed as a general methodology of software development nowadays. This all is covered by the software configuration management (SCM), which underlies the general configuration management (CM). Besides project management the area of SCM has quite similar importance. Its absence very likely leads to serious issues during software quality assurance checkpoints or during a delivery process in general. The eventual exposition is increased time to deliver of budget cost. For fix price project this would be a disaster. The amount of resources related to SCM or CM in general is quite rich, unfortunately often offers only too general point of view or obvious facts. If one searches for specific and directly applicable methodology he will fail, I assume. My such research and investigation in the area failed either. Rough idea of labels promotion what I’m aware of comes from approach implemented upon versioning system of name Clear Case from the Rational 1 company. The versioning system itself is strictly commercial and expensive, on other hand the details of the approach were not exposed to me or any public due to its proprietary nature. With keeping the SCM’s importance in mind and based on absence of third party solution to use or to build on, this master’s thesis project sets to itself an ambitious aim to provide (if possible) generalized versioning approach and a set of tools to technically support that.
1 Note: The Rational Company developed several tools to support development, mainly to increase code quality; in majority for UNIX system. The company has been bought by IBM. vi
Table of contents
1 Introduction ...... 1 1.1 Overview ...... 2 1.2 Terminology ...... 2 1.3 Common inappropriate usage of a versioning system ...... 6 1.3.1 Case study ...... 7 2 Source code versioning approach ...... 8 2.1 General assumptions...... 8 2.2 Main goals overview ...... 8 2.3 Actors ...... 9 2.4 Predefined label tags ...... 10 2.5 Who is applying the label ...... 10 2.6 Disposition of labels...... 10 2.7 When to label...... 10 2.8 When to label for a first time...... 10 2.9 The defect tracking cycle...... 12 3 Preparing a release – deploying with versioning system...... 13 3.1 Considerations for following example...... 13 3.2 The approach ...... 13 3.2.1 Zeroth step – put new release label across repository...... 13 3.2.2 Step one – extract list of files to be released from bug tracking tool...... 14 3.2.3 Step two – move the new release label, i.e. promote the revision...... 14 3.2.4 Step three – obtain all files of new release ...... 16 3.2.5 Step four – build the release package ...... 16 3.2.6 Step five – completion...... 16 4 Branching approach ...... 17 4.1 General assumptions...... 17 4.2 Proposed solution ...... 17 4.2.1 When to create a separate repository ...... 17 4.2.2 How to create a separate repository...... 18 4.2.3 How to work with separate repositories – the approach basis ...... 19
vii
5 The tools ...... 20 5.1 General assumptions...... 20 5.2 Target versioning system...... 20 5.3 Pre implementation considerations...... 22 5.3.1 The repository access approach...... 22 5.3.2 CVS repository database format files...... 22 5.3.3 CVS repository database format folders...... 24 5.3.4 CVS repository database location ...... 24 5.3.5 CVS local checked out copy admin structures...... 24 5.3.6 The programming language...... 25 5.4 The implementation...... 25 5.4.1 Common functionality...... 26 5.4.2 The developer space tool – mklabel ...... 27 5.4.3 The release manager space tool – cvs_rcheck ...... 28 6 The conclusion...... 33
7 Literature and resources...... 34
A Appendix ...... 35 a. The cvs_rcheck script output...... 35 b. An example of history graph of a file in VS repository...... 36 c. The mklabel in action ...... 37
viii SOFTWARE CONFIGURATION MANAGEMENT
1 Introduction
The source code versioning itself, or also known as revision control is nothing special to be explained these days. Thus let’s just briefly mention that it’s based on principle of several versions – so called revisions – of the same object or unit of information; in the area of software engineering it’s typically a source code of configuration file, binary object respectively. A revision is ordinarily identified by its number. On top of this there lies a concept of marking a revision by a tag, creating some kind of alias, virtual revision identifier, the label. This happens on s single file level; while it’s an organized group of versioned objects, together with wrapper handling versioning operations, it’s to be called repository, or versioning system respectively. The versioning system aims to store revisions, but this is not standalone functionality. This way it provides overview of changes done, when and whom by – important thing, but the focus to mention is the idea to assist or support the project (application) build, which is a part of release management. The release management has builds up on versioning system and provides as an outcome the (software) release. Release is basically the delivery. To deliver the release, it always goes through several project stages, i.e. the test stage for instance. To each stage, to each its environment the release shall be deployable as smoothly as possible. Any unexpected major issue cost the project a lot from project management point of view. Deployment is ergo one of the significant parts of the delivery process. But it’s fully dependant on the release quality. The dependency consequently descends in cascade to the versioning system usage. This is to be controlled by the release management. So the résumé is that to have a full control over deployment and to avoid any issues during that related to quality and the fullness of the delivered release, the release management is major actor. Versioning system shall support the release management, but the prerequisite is the right information about the versioned objects. And this needs to be stored by the most appropriate actor, by somebody who actually does the versioning system interaction from bottom perspective – by the developer. While there is set approach of tasks and steps for each actor and the tools take place, the release quality assurance is a must, inherited consequently to the deployment process either. This master’s thesis provides both – the approach (or methodology) to follow up by the actors and the tools to interact with the versioning system and check the consistency of versioned data. The deployment process this way employs the release management based on revisions control to achieve desired quality the delivery. 1 SOFTWARE CONFIGURATION MANAGEMENT 1.1 Overview
This master’s thesis report deals with the tools and their implementation in the last few chapters. The versioning and release management approach is set up after the terms are explained to the reader. The report begins with to the terminology explanation followed by examples of improper versioning system utilisation (as observed this is right to be mentioned due to its still occurrence in the real praxis). The way of presentation of the terms has been chosen to be as much clear and structured as possible with focus on visual interpretation 2. 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 files 3 needed for runtime, configuration file(s), all other files 4 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 object 5 to be versioned; possibly a wrapped on single file revision control tool. Repository (REPO) – structured and organized group of versioned object, a database where versioning system stores the revisions of each versioned object; typically flat text file based database, often capable to be parsed by external tools
2 to follow this I dare have prepared drawings to visualize the discussed matter. 3 libraries, shared objects, scripts, third party delivered binaries etc. 4 examples: license file, data files etc. 5 (mainly) plain text files (source code, scripts, configuration, data) as well as binary files (executables, libraries, binary data, archives etc.) 2 SOFTWARE CONFIGURATION MANAGEMENT Repository module logical partition of repository represented by the name, commonly it’s subfolder of repository of such a name (e.g.
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 one 7.
6 the reason is that not every file is being updated with the same frequency 7 each of labels appearing on a single file can represent different release versions where the single file is participating in; on other hand the same revision can be used for several releases (usually in row) and updated for some later version, e.g.: r1.1 >v1.0.0; r1.2 >v1.1.0, v1.2.0, v1.3.0, v1.4.0; r1.3 >v1.5.0 3 SOFTWARE CONFIGURATION MANAGEMENT
Figure 1.2 Label(s) presence on single file
Figure 1.3 Label presence from repository point of view; every single file has got the same label, but pointing to the different revision file1.c file2.c file3.c file4.c file5.c
1.1 1.1 1.1 1.1 1.1 LABEL
1.2 1.2 1.2 1.2
1.3 1.3 1.3 1.3
1.4 1.4 1.4
1.5 1.5
1.6
4 SOFTWARE CONFIGURATION MANAGEMENT Figure 1.4 Shows how the label puts different revisions of different files virtually to one line. The line represents one specific release.
file1.c file2.c file3.c file4.c file5.c
have a look at 1.1 this ‘level’
1.2
1.1 1.3
1.1 1.2 1.4 1.1
1.2 1.3 1.5 1.2 1.1 LABEL
1.3 1.6 1.3
1.4 1.4
version 1.5 e.g. release v1.1.0
Label moving – technically means a change where the label is pointing to. When the label has been moved points to other revision of the same single file. Technically could be realized as atomic removal of existing label and creation of another one with the same name. Example situation when the label moving is needed: developer did put an updated file after a bug fixing into a versioning system and now needs to label the new created revision as test ready (instead of the previous one).
Figure 1.5 The situation when head revision of the file has been promoted to be test- ready.
5 SOFTWARE CONFIGURATION MANAGEMENT Check-in – alias for commit in versioning system world; puts new revision of versioned object into the versioning system. Common prerequisite is that versioning system needs to know the object, i.e. it needs to be added firstly. Check-out – gets local (so called working) copy of a project from versioning system. Checked out can be whole project, module or subfolder. Many versioning systems support single file check out. In general technically it creates local copy as well as local control structures of versioning system and its tools. Update – gets specific or latest revision of file (or files) from versioning system; updates local copies. Do not mismatch with repository side update, i.e. check in. Common prerequisite is checked out structure where the file(s) located is(are). Defect (DT) any bug within the software to be delivered8 Change request (CR) any requested change in the functionality or code not based on a found defect, in other words any update of functionality or code based on request to modify original requirements
1.3 Common inappropriate usage of a versioning system
Usage similar to central storage point • miscellaneous files are being checked in without having any structured approach; not following any (or just weak) naming convention for files, directories and repository modules neither • revisions of the file are not stored as another commits of the same filename but as several checked in files with different filename containing some post fix declaring a version Labelling usage misunderstood, rare or none • release source code is checked out form versioning system, built, packaged 9 and consequently the package is checked in into a VS and labelled as the release (excellent wrong versioning approach instance; to use VS for a release package storage is quite ok, but the labelling concept is completely misplaced while used in such a way and should take place much sooner before) Developer’s semi finished work saved into a versioning system, what prevents the freshly checked out (the latest) project version even from being built or compiled; New version to be released considered as the set of latest revisions and its retrieval from VS exactly in this manner by “get latest” functionality (command).
8 to be considered as an official defect, not one found during unit test, usually found during an official project’s test phase 9 usually package does not contain application sources but built binary objects; however even if package consists only from some plain text files (of scripts for instance) the methodology of this kind is wrong 6 SOFTWARE CONFIGURATION MANAGEMENT 1.3.1 Case study
(Note: The following case is not a real case study in right sense o the expression due to the fact it really happened) The deployment of new version on the application to the testing environment was triggered by the regular schedule set up within the project. That requested the new release to be built. Release manager announced the code freeze timeline and at the certain time put a label across the repository, tagging al the head revisions as the ones to be released as the new application version. Onward he retrieved the release form versioning system and built it into the release package. The package was deployed to the testing environment. Shortly afterwards, during first test a new critical defect was found and raised. The team decided to deliver an on demand hot fix due to quick possibility to fix that. The responsible developer performed the defect fix in source code level, did commit the change into the repository. Release manager issued extra hot fixed release with the same approach as recently for the regular release, what was deployed to the test. Immediately the blocking issue was raised and the complete end to end testing stopped for the day. Investigation found the reason: during the hot fixing some other developer(s) did commits of source code not supposed to be released. But without having approach to select specific revision for the release on single file level as well as without any consistency check they didn’t have control over the delivered content. By this the deployment completely failed. This example case shows clearly the need of appropriate usage of a versioning system and a need of well defined, structured and clear software release management, i.e. good software configuration management, which is subject to the overall deployment process and application delivery. This master’s thesis project asset shall prevent such a issues from happening.
7 SOFTWARE CONFIGURATION MANAGEMENT
2 Source code versioning approach
2.1 General assumptions
(To be comprehended as the requirements on the approach itself and on the software tools later on) Approach supports the release management which is employed by the deployment process from delivery point of view. All changes or updates are to be tracked in a defect or change request tracking tool. All requested and changes done need to be entered in there. A developer is requested to fill into a bug tracking system a list of new, changed, removed files and/or directories relevant to the defect/change request while he(she) describes the bug fix solution. Paths are to be relative to check out point. The developer is requested to commit work daily. The minimal extent of checked in update is to preserve ability to compile the application/project while any team member checks out the latest version. Idea behind is to safely store all the work done to avoid any time (resources) loss (and money loss consequently). On other hand there needs to be a solution how to ‘mark’ a revision as ready to be tested or released, because commonly it won’t be the latest one always. Moreover, there is a need to separate a developer from using various versioning system commands and parameters due to labelling purposes as well as from entering the label manually to avoid any incorrectness, even just mistyping. Finally, the release manager has to have an ability to check the consistency between a versioning system and a bug tracking tool. This is supposed to be as much automated as possible. One repository could contain several systems (modules) included to the project (application), but the release can regard single module, subset of modules respectively, thus a feature to skip a check of list of modules is required.
2.2 Main goals overview
Let’s go shortly through the list in the structured way: • include to the release and deploy consequently only and only the files of the revisions which are supposed to be there • enable at any time precise overview which revisions of the files make the release
8 SOFTWARE CONFIGURATION MANAGEMENT • enable retrieval of any version released in past on demand in future without explicitly spent effort • make possible to be in line with status in bug tracking tool • catch up any inconsistency between versioning and bug tracking system • to preserve ability of a developer do another commits after the one considered as test ready while the release consistency is not harmed • basically have the full control over the objects released and the revision chosen on a single file level
2.3 Actors
Human: The basic role is the developer (DV). He is who provides the content to version and further to be released. He knows the object to deliver, thus he provides the info which its revision is the one to be labelled, i.e. released. Configuration manager (CM) is the actor who checks the consistency between versioning system and bug tracking tool, performs needed interventions. Release Manager (RM) is preparing the release by employing the data (tags) set by the developer and applies the labelling techniques. Frequently the role is combined with configuration manager, definitely not exclusive against role of developer (general situation on small sized projects). Code migration responsible person (MR) the one responsible for merging changes within different developmental branched. In our proposal for merging between repositories of modules representing different major releases. Application: Versioning system (VS) – can stand for almost of any kind of revision control system capable of the labelling and label moving Bug tracking tool (BT) can be a tool which provides functionality of DFs or CRs records with saving the status and comment possibility. Included access and user management suits more as well as an extra data to store, the environment for instance. (Note: roles are not exclusive to each other, perhaps only the groups)
9 SOFTWARE CONFIGURATION MANAGEMENT 2.4 Predefined label tags
Basically there are two kinds of a label to consider. From the developer’s side it’s the test- ready label (e.g. test ready). Release manager takes care of the release label (e.g. v1.1.0 10 ).
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 applied 11 – 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 label 12 (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 FAT 13 . ‘Code freeze’14 time line has to be introduced at
10 technically wouldn’t be possible to store exactly in form of ‘v1.1.0’ for instance ; if so, common labels look like ‘V1_ 1_0’ instead 11 Before finally applied the labeling methodology enforces once to move of the release label – the promotion to the new release. 12 label could be for instance ‘PATCH_NO 0123456’ 10 SOFTWARE CONFIGURATION MANAGEMENT this time based checkpoint all software revisions are considered as test ready, i.e. labelled with test ready label. For purposes of very first release all files with test ready label are labelled by the release tag. Figure 2.1 Labelling has been applied for the very first time. There is no other release label except initial-version and test-ready label, both pointing to the same revision of a single file.
13 FAT ~ Factory Assembly Test; single module of system included to project is being tested without interconnectivity nor interaction with other modules or systems; maximally the stubs are used 14 ‘code freeze' is an expression for disallowance of another code commits to versioning system; a need for this pops up when the first release related labels are going to be applied (test ready and release label, e.g. v1.0.0); because there was no test ready revision so far, the one delivered at ‘code freeze’ time is the one 11 SOFTWARE CONFIGURATION MANAGEMENT
2.9 The defect tracking cycle
The diagram represents the actions flow and shows when and what to label during development (fixing, testing) project phase.
Figure 2.2 The defect tracking cycle [8]
Under Discussion Test Commitee Postponed No Defect Defect is Defect is closed closed
2. Assigned Under Solution is Repair Delivering the fix identified Review of the defect (Developer) (Dev. Lead) - Fill in changes made - Name new, deleted and changed files - Label files in VS Implementation of as test-ready Review of the bug solution Dev. Lead (Developers) Test lead
5. Reopened 1. New Defect is 6. Solved 3.Repaired A defect is reopened after Defect is Defect is found testing closed corrected
Closing defect ( Test Lead) A defect is found during ( Dev. Lead) test execution (Test lead / Tester) Retesting of solution (Test Lead / Tester)
Delivering the release Reopening of bug (Configuration manager) (Test lead / Tester) 4. To test Defect is - Label files with release delivered tag in VS Not to the testing - Build package Solved environment - Create release notes
12 SOFTWARE CONFIGURATION MANAGEMENT
3 Preparing a release – deploying with versioning system
3.1 Considerations for following example
Let’s consider the last released version has been v1.0.0 and new one to release is v1.1.0 Figure 3.1 Example of labels layout in VS repository on single file level. Two labels present, pointing to different revisions.
3.2 The approach
Let the reader by guided through the actions to take. The focus is to keep small, clear and isolated steps, i.e. to keep it as simple as possible.
3.2.1 Zeroth step – put new release label across repository
Put the label of new release onto each file which has got last (previous) release label and let it point to the same revision of the single file, i.e. new release ~ last release.
13 SOFTWARE CONFIGURATION MANAGEMENT Figure 3.2 Status of single file after the zeroth step. Observe the new release label being added and pointing to the same revision as the older one
3.2.2 Step one – extract list of files to be released from bug tracking tool
Obtain a list of updated (new) files which are filled into the BT for each specific bug fix (implemented CR respectively) and are supposed to be delivered (i.e. BT status of the bug is ‘repaired’ 15 ). Run consistency checker on the repository against list of updated files to be released and check the result, perform necessary fixes 16 in VS and correct the list of files to be released if required.
3.2.2.1 What could be a VS repository inconsistency There are several potential possibilities: • file is modified in VS, not listed in BT for any ‘repaired bug’ • file is modified in VS, not labelled as test ready • file is not modified in VS, listed as modified by a bug fix in BT • file is not checked in into VS, listed as modified by a bug fix in BT • file is not checked in into VS, has no label at all
3.2.3 Step two – move the new release label, i.e. promote the revision
Move recently placed new release label from old release revision to one labelled as test ready, i.e. make release label to point to the same revision of single file as the test ready label does. This is to be performed for each file from list of files to be released.
15 to check the defect statuses refer to the chapter 2.9 “The defect tracking cycle” 16 for example when the file is listed as to be promoted (with its new revision) to the new release, but the test ready label points still to the older revision the developer probably has forgotten to apply the label after check in; the action to take is to move the test ready label to proper revision 14 SOFTWARE CONFIGURATION MANAGEMENT Figure 3.3 Status of single file after the second step. See the new release label moved to other revision, i.e. ‘v1.1.0’ label points now to the ‘test-ready’ labelled revision
3.2.3.1 What happens with not modified file Not modified file is a file in VS repository without a new revision checked in.
Figure 3.4 Status of single which has not been modified from last release. Head revision has
file.c the test-ready label as well as the last release label.
1.1 v1.0.0
1.2 test-ready
In the zeroth step there is applied a new release label on the same revision as previous release. Figure 3.5 Status of a single - not modified - file in VS repository after the zeroth step. Head revision has the test-ready label as well as the last release label – on top of it the file.c label of new release is added, pointing to the same revision as previous one.
1.1 v1.0.0
1.2 test-ready
v1.1.0
Due to that there is no newer revision, this file is not listed in BT and could not appear as inconsistency within VS repository check. No other step will affect this file and revision labelled as new release will be delivered within new release (technically that is the same revision as the one which has been released as the previous version). In this example: as v1.0.0 has been released revision 1.2 and as v1.1.0 shall be released revision 1.2 as well. If there in the future won’t be any modification of the file, any new label points to the same revision as previous one, i.e. to the one still labelled as test ready. 15 SOFTWARE CONFIGURATION MANAGEMENT
Figure 3.6 status of a single file in VS repository after many new release labels have been applied and the file is kept unmodified; i.e. all the labels point to the same revision (in this example to the 1.2). file.c
1.1 v1.0.0
1.2 test-ready
v1.1.0
v1.2.0
v1.3.0
v1.n.0
3.2.4 Step three – obtain all files of new release
Checkout or get all files supposed to be delivered within new release (or which are necessary to create/compile this software release), i.e. obtain from VS all the files with the new release label, e.g. with ‘v1.1.0’ label.
3.2.5 Step four – build the release package
Compile; do necessary steps like reconfigure installation configuration file and create new release installation package as required by the project design or policy.
3.2.6 Step five – completion
Create release notes, mention all deployed bugs and change requests (included in the package) and update the status of relevant bugs in bug tracking tool. Finally store the package in the agreed location together with the release notes and best create checksum file for transfer and check purposes.
16 SOFTWARE CONFIGURATION MANAGEMENT
4 Branching approach
4.1 General assumptions
When there is a need of development of a new major release, and current major release needs to be continued with bug fixing etc., the branching of the development, i.e. branching of the source codes and configuration shall be introduced. There are two way to follow on general. First one is widely accepted and used – the branching within the same repository by using branching functionality of the versioning system. As a benefit can be possibility to use built in features for change within different branches merging. The second way is to establish a separate repository copy for the new major release. The benefit is prevented complexity of interactions with versioning system, especially from the developer’s point of view. Disadvantage is no away of automatic branches merging. None of the solutions seem to be the perfect one from the first look. Natively I would choose the regular and used inner branching. On other hand the developers are not always capable to handle the operations with a versioning system. More complexity added on top looks to me as contra productive. To get more information and input the internal survey did happen within the circle of most experienced project team members. Finally the decision took place, based on all the gathered data.
4.2 Proposed solution
Establish new separate repository by checking in stable release version (best final, e.g. v1.0) of the current software development line (obtained from existing repository).
4.2.1 When to create a separate repository
In the ideal case the best timeline is when complete and tested – stable – current release is ready. In the common real case if final major version of current release is not available and there is a need to start with development of new release (e.g. due to limited time), the timeline is presence of last stable minor release in highest development phase (with most of functionality included).
17 SOFTWARE CONFIGURATION MANAGEMENT 4.2.2 How to create a separate repository
The steps 1. checkout latest stable release from existing repository as a local working copy 2. establish new separate repository for new development line 3. check in obtained local working copy into new repository
Figure 4.1 New repository establishing procedure
file.c
1.1
1.2
1.3 timeline which triggers creation of another 1.4 file.c development line check out form the old repository v1.0.0 1.5 2.0 v2.0.0 and check in into the new one
1.6 2.1
1.7 2,2 fixing
2.17
2.n v2.1.0
development
Extra possibility is just to directly clone the repository if the versioning systems allows (basically to prevent any commits from being done during the operating). This may require resetting of the revision identifiers to new sequence, e.g. from 1.22 to 2.1.
18 SOFTWARE CONFIGURATION MANAGEMENT 4.2.3 How to work with separate repositories – the approach basis
Existing account of a developer is considered as development line 1 oriented. New account for the developer shall be created and configured to connect to (work with) new repository and considered as development line 2 oriented. Separate database user and schema shall be created if needed for each developer with numeric suffix for the new account (instance of software being developed)
19 SOFTWARE CONFIGURATION MANAGEMENT
5 The tools
5.1 General assumptions
The versioning and release management approach as designed above, earlier in the document, need the supporting tools to be in the place. As required either a developer needs to be shielded from direct usage of any versioning system commands with all necessary parameters to put the proper label. Probability of even as simple issue as a mistyping is quite high. Experience shows as well that people aren’t paying much attention to repeating tasks. And applying of test ready label occurs in general repeatedly and frequently. The approach of the release build using versioning system requires a consistency check of VS against BT. This is supposed to be handled by a separate tool. The outcome is, that the minimum set of tools is • tool to apply test ready label on the file specified • tool to check the consistency between versioning system and bug tracking tool The extra decision to make is which versioning system to use and build the tools for. The things to consider are the scope of usage of the system nowadays, reliability, standardization, commerciality, openness of the code and the repository database format, cross platformness, presence of the manuals and documentation and other minor values like any frond end presence etc.
5.2 Target versioning system
As the versioning system has been chosen The Concurrent Versions System, the well known CVS. CVS is very spread, very used (commercial and free/open source projects as well including many major project of this days); “CVS is a production quality system in wide use around the world” [1], “CVS is the most popular version control system available today” [2]. It’s reliable, robust, well documented; repository is plain text based and capable to be parsed by external tools. CVS does support client server architecture as well as user management, exists in ports for many platforms even as binary package, moreover is open sourced. Where CVS loses a credit is inability to version the folders itself and UN*X file system symbolic links. That is possible to be handled with some workarounds, anyway. 20 SOFTWARE CONFIGURATION MANAGEMENT The other, CVS based versioning system, the Subversion alias SVN, solves these missing things and has got all the great CVS functionality. On other hand – unfortunately – in the time when the development of this project has started the SVN was not developed to the production level, so it was excluded from the list of possible systems. However, future SVN port of the tools should not be a too big deal. Microsoft’s versioning product – the Microsoft® Visual SourceSafe™ is not able to handle label properly in manner as all the common versioning systems do; the repository is fully operable only via graphical front end (at least the command line tool is not properly documented); repository is of proprietary binary format; real life experience shows it’s terribly slow while accessed concurrently, frequently even during single user access. The big drawback is that, it’s not reliable: when a network problem occurs, it corrupts repository file (not just last revision, but complete history for the file)! On top of all, there is an announcement on Microsoft web site that this tool is supposed to be used just for small teams/projects (any investigation if they did any progress with this system meanwhile has not been done). All this brought this system out of the game of consideration. Hints: if one misses a possibility to use CVS as a versioning system while developing under Microsoft® Visual Studio™ for instance on a Windows system he should be told about existence of several free project of CVS and MS world IDE’s integration: • JalindiIgloo ( http://www.jalindi.com/igloo/ ) – MS® Visual Studio™ plug in for CVS (complex and a bit buggy); • ToitoiseCVS (GPL; http://www.tortoisecvs.org ) shell extension to work with CVS by mouse “right click” from Windows Explorer; very comfortable tool; this way of work with a versioning system is more advisable than direct saving from editor via plug in; experience shows that a developer pays more attention to interactions with a versioning system while this is manager extra an IDE where he(she) develops in, which is worth for the thing, indeed. • WinCVS ( http://www.wincvs.org ) – A set of GUI front ends for CVS written in C++ and distributed under GPL, with native look and feel on Windows, Mac and Unix/Linux thanks to the use of popular GUI frameworks like MFC, CJLibrary, Metrowerks PowerPlant and gtk+ [5]; • CVS SCC proxy (http://www.pushok.com/soft _cvs.php ) the SCC API plug in which provides access from practically all Microsoft SCC enabled software to general CVS repositories. The Microsoft SCC API is supported by: MS VC 5.0 7.0, MS VB 5.0 7.0, MS .NET, MS FrontPage, MS DEV and other Microsoft development tools. With the support of 3rd party tools this plug in can be used by Borland IDE's [6].
21 SOFTWARE CONFIGURATION MANAGEMENT 5.3 Pre-implementation considerations
5.3.1 The repository access approach
The ways of accessing the versioning system repository while the CVS is chosen are either directly parse the plain text based repository files or parse the output of CVS tools which will access the repository. The first way is possible, the format is well documented. The second possibility is doable as well, CVS tools output format is claimed as kept preserved and capable to be parsed by standard UN*X tools 17 . Implementation will aim the first way – to parse the repository directly, taking the advantage of the only prerequisite to the consistency check just the repository copy and the tool presence.
5.3.2 CVS repository database format - files
CVS is technically a management layer on top of RCS files – a CVS repository object is a RCS file.
(Follows [4] quotation) An RCS file's contents are described by the grammar below. The text is free format: space, backspace, tab, newline, vertical tab, form feed, and carriage return (collectively, white space) have no significance except in strings. However, white space cannot appear within an id, num, or sym, and an RCS file must end with a newline. Strings are enclosed by @. If a string contains a @, it must be doubled; otherwise, strings can contain arbitrary binary data. The meta syntax uses the following conventions: `|' (bar) separates alternatives; `{' and `}' enclose optional phrases; `{' and `}*' enclose phrases that can be repeated zero or more times; `{' and '}+' enclose phrases that must appear at least once and can be repeated; Terminal symbols are in boldface ; nonterminal symbols are in italics . rcstext ::= admin {delta}* desc {deltatext}* admin ::= head {num}; { branch {num}; } access {id}*; symbols {sym : num}*; locks {id : num}*; { strict ;} { comment {string}; } { expand {string}; } { newphrase }*
17 [f,e]grep, [s]ed, awk for instance 22 SOFTWARE CONFIGURATION MANAGEMENT delta ::= num date num; author id; state {id}; branches {num}*; next {num}; { newphrase }* desc ::= desc string deltatext ::= num log string { newphrase }* text string num ::= {digit | .}+ digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 id ::= {num} idchar {idchar | num}* sym ::= {digit}* idchar {idchar | digit}* idchar ::= any visible graphic character except special special ::= $ | , | . | : | ; | @ string ::= @{any character, with @ doubled}*@ newphrase ::= id word* ; word ::= id | num | string | : Identifiers are case sensitive. Keywords are in lower case only. The sets of keywords and identifiers can overlap. In most environments RCS uses the ISO 8859/1 encoding: visible graphic characters are codes 041 176 and 240 377, and white space characters are codes 010 015 and 040. Dates, which appear after the date keyword, are of the form Y.mm.dd.hh. mm.ss, where Y is the year, mm the month (01 12), dd the day (01 31), hh the hour (00 23), mm the minute (00 59), and ss the second (00 60). Y contains just the last two digits of the year for years from 1900 through 1999, and all the digits of years thereafter. Dates use the Gregorian calendar; times use UTC. The newphrase productions in the grammar are reserved for future extensions to the format of RCS files. No newphrase will begin with any keyword already in use.
(end of [4] quotation)
23 SOFTWARE CONFIGURATION MANAGEMENT Each versioned object has the history file within repository, having the same file name as corresponding object with ‘ ,v ' appended to the end.
5.3.3 CVS repository database format - folders
CVS repository contains basically folders of following kind: • administrative files location (
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 location 20 .
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 repository 21 . This is one of the possible sources where the tool can obtain the repository path, alias CVSROOT.
18 used to store the objects removed from active project and kept for history data repository lookup (retrieval an old project release for instance) 19 there is no relevance between internal CVS data and subject of the consistency check; in other words there is no reference between CVS internal data and BT data 20 e.g. /usr/local/cvsrepos 21 where the local copy has been checked out from 24 SOFTWARE CONFIGURATION MANAGEMENT 5.3.6 The programming language
The language to develop the thing in shall be determined by the major functionality and tasks required to be done by the tool. For a first is would get the data by parsing the repository database, secondly with lower severity a comparisons are to be done. No special real time functionality needed. Best for text data parsing are scripting languages. Well known PHP suits best for a web based development, Perl is pretty fine for the purpose, but the code might not be as nicely readable as expected, but more important is that Perl is not installed on a regular UN*X system per default, hence it increases the tool prerequisites. To keep it simple and straight forward to implement and to minimize the prerequisites to the system, the UN*X shell scripting is the solution, with employing (just only) the standard UN*X tools, the AWK in major. Such a solution is fully capable to parse the input data as well as to do the rest of required functionality. For efficiency the GNU tools are to be used, but with the functionality in line with POSSIX norm. Résumé: CVS is the versioning platform; OS UN*X; application code: BASH based script including AWK code, employing standard UN*X tools, the POSSIX based functionality.
5.4 The implementation
The tools are to be implemented on UN*X system platform. Thus naming convention for them shall follow the UN*X standard, the parameter names shall mimics the convention of CVS. The tools resides in two working areas • The Developer space • The Release Manager space The first one makes a test ready label to point to the last checked in revision of a file; it has name “mklabel”. The parameter is to be only the file name which the label should be put (make) on; the CVSROOT data is taken automatically from local control folder or eventually from shell environment (aim is to prevent the user from a need to specify the obvious information; if the control folder isn’t present the check in is not possible anyway). The second one – the checker of CVS consistency against data from BT – has got name “cvs_rcheck”. The “r” in the name follows convention of CVS: for an action upon repository files directly 22 it has “r” in the parameter name 23 ; the cvs_rcheck is supposed to perform only repository direct action.
22 so called “remote” action 23 for instance rlog, rtag 25 SOFTWARE CONFIGURATION MANAGEMENT The inputs are to be specified from command line as positional parameters. The naming convention follows the one of CVS. It tries to retrieve the needed data locally if possible, complains when missing. The command line parameter overrides the data found locally. For the parameters list is the best to refer to (usage) help message of the script.
Figure 5.1 Help message of the script
USAGE INFO:
cvs _rcheck
Supported parameters list: -d CVS repository path (e.g. /usr/local/cvsrepos) default: TEST _READY
Input source priority (higher no. ~ lower prio.): 1. explicitly specified value of the "-d" parameter 2. ./CVS/Root file content 3. exported CVSROOT environmental variable
-r * CVS 'Release' label/tag (e.g. R1 _10 _2) default: n/a -t CVS 'Test-ready' label/tag default: TEST _READY -l * list of files to be promoted default: n/a -x list of modules to exclude from the checking default: n/a -o output log directory default: /tmp
* - mandatory
To print out this usage message -[?|u|U|h|H] --[help|usage]
5.4.1 Common functionality
Both the tools need due to the nature of their major functionality or necessary checks – to implement functionality to compare revisions.
26 SOFTWARE CONFIGURATION MANAGEMENT The revisions are represented in textual form as digits separated by the dot (“.”) character. While branching isn’t used, all the revisions are to be of the form X.Y, where both X and Y fit pattern [0 9]+ (digit of at least one occurrence; e.g. 1.24). Branched revisions (form of X.Y.Z.W, i.e. containing more “dots") are not supported in this version. Only one branch revision taken into the consideration is the one created during very first import into the repository after its setup. The import creates branch; while the repository is empty so far it makes revision to appear on an import branch as well as on the main regular branch. First regular checked in revision is 1.1 and first branch revision is 1.1.1.1. They are technically the same, but the check if a case hits this scenario is implemented. Basically there is one function, AWK based, performing revisions comparison and called compare _revisions . Parameters to be passed are two strings representing revisions to compare. Result is returned is the exit code (follows UN*X scripting conventions). Exit codes: # exit code(s): (i.e. which one is bigger;) # 0: $1 = $2 (no one) # 1: $1 > $2 (the first one) # 2: $1 < $2 (the second one) Example of function call: compare _revisions $REV _TST $REV _REL; which for instance could be expanded to compare _revisions 1.12 1.9; and the result code in such a case is 1 or special case compare _revisions 1.1 1.1.1.1; if fits to “first import“ schema it returns 0
5.4.2 The developer space tool – mklabel
This tool is supposed to be as simple as possible to make developer’s life easier. Only parameter which needs to be passed to the tool is the name of file where the label is about to be applied to. The rest of the necessary data is gathered by native CVS command tool used within the script (technically from the UN*X shell environment or administrative CVS subfolder).
27 SOFTWARE CONFIGURATION MANAGEMENT Technically the mklabel tool is a wrapper around native CVS command “cvs”; mklabel does all the checks before the tag is applied to avoid situation that the test ready label points to incorrect revision. The circumstances under which the user is able to successfully execute the tool are quite strict. For a first the current directory is required to be the one where the to be labelled file located is, for a second only single file can be specified at once, moreover is there is detected any stickiness on the local copy of the file the user is announced and needs to confirm explicitly continuation of the operation – that all shall prevent the developer from usage of the tool in recursive manner, which can potentially lead to labelling of more files than the ones supposed to be test ready; or accidentally label wrong revision, respectively. Aim is to force the developer to do simple and clear steps during the label applying procedure.
Figure 5.2 Usage syntax of mklabel
mklabel ./
e.g.: mklabel ./http_lib.c
5.4.3 The release-manager space tool – cvs_rcheck
The tool implements basic features as well as a set of extended ones to be able to check status of each single file in the repository and compare gathered information against data from bug tracking tool to discover any inconsistencies. Basic features: • get CVSROOT to be aware of CVS repository location; firstly is tries to use UN*X shell environmental variable $CVSROOT , if not found the lookup is done in the local CVS administrative folder to the file which stores the data, i.e. to the ./CVS/Root ; all this – as mentioned already in this chapter – can be overridden by a command line parameter, the “ –d” • get CVS status from repository for a file (to retrieve list of labels and corresponding revision numbers) • get CVS log of the file (to gather the data to distinguish between the revision in the explicit way; basically needed to verify the scenario of identical revision 1.1 and 1.1.1.1) • from retrieved data extract revision number related to the specific label (to the test ready and to release label either; release label is one of the mandatory parameters to be specified from the command line)
28 SOFTWARE CONFIGURATION MANAGEMENT • get list of files to be promoted to be included to the new release (plain text based, each file name on a separate line; UNIX newlines /0x0A/ are a must) • to output and log the results for each file detected within the repository; prefix of output and log files can be modified by the input parameter, the “ –o” Extended features: • to be able to skip a set of repository modules during the check; the set is represented as a plain text file with module name on a single line (UNIX newline characters are required), comments are supported and defined as a line(s) beginning with the sharp (“#”) character; the file name is to be passed to the tool as an extra input parameter, the “ –x” (derived from “list to e xclude”) • map the reported and logged file names to the path format relative to potential check out point in order to use the script output data directly (i.e. simply copy&paste); mapping data is gathered directly from repository control and configuration data (the $CVSROOT/CVSROOT/modules file) The first extended feature has not to be necessarily used, but on other hand becomes very helpful when the repository stores several different sub projects (as modules) and the release manager is going to check the consistency (prepare new release in other words) only for a specific sub set, specific list of modules. In such a case it suits best to exclude not needed modules from check to avoid their content as inconsistency in check result. The second extended feature, so called module mapping, automatically takes the data from
Figure 5.3 List of modules to exclude (file content)
cvs _rcheck-module _exclude _list.txt: # -- main application #server _module server _module _lib # -- migration team migrator migrator _ddl configuration file mentioned above and parses it to get the settings to be able map the path properly. If there is no module mapping configured in the repository, the feature is silently skipped. Having output in a convenient format increases efficiency of release manager when there is a need of manual intervention to the repository (even simple check).
29 SOFTWARE CONFIGURATION MANAGEMENT
Figure 5.4 Module mapping schema instance
CVSROOT : /usr/local/cvs _repo/ Module: server _lib CVS module configuration: server _lib ~ server/lib (which says that module ‘server _lib’ should be checked out to ‘server/lib’ folder relative to checkout point) Example of full path in repository module: /usr/local/cvs _repo/server _lib/http _lib.c Example of full path in checked out local copy: /home/marek/devel/server/lib/http _lib.c (while checkout point is ~/devel/) Mapped path of http _lib.c: server/lib/http _lib.c
Both module check exclusion and module mapping are designed and implemented to be performed in the way of a single sed script (script of regular expressions in format interpretable by UN*X tool “sed”). The script is compiled during initialisation phase of the tool and handles all the modules at once. There are two major outputs of the tool – standard output and file logging. To the standard output is printed first summary information before the check run begins and during execution there is information of processed file and its status from the check as well as the found revision numbers; filename format is relative to checkout point (module mapping takes action). The file logging splits itself into the three channels: log file, csv 24 file and xls 25 file • the log file entry consists form file status, revision numbers, mapped file path and absolute path repository within repository; ends up with the processing time statistics (start time, end time) • the csv file entry is the same as log entry except absolute path, fields separated by semicolons (“;”); purpose is to be processed if needed by external tool • the xls file mimics csv file and extends features by adding colour highlighting to rows according the status of the file ok, file status is new and consistent – green background ok, file status is unmodified and consistent – default background kept not ok, file status inconsistent – red background the format of the xls is not binary one; Microsoft has introduced an extra format of xls files since office version 9: basically a kind of xml + html + css based format (one
24 plain text file with comma separated values on a line 25 MS© Excel Sheet. 30 SOFTWARE CONFIGURATION MANAGEMENT can call it xhtml format); this allows to generate an xls file instance directly from a UN*X shell script with taking an advantage of plain text output to a file. First html container for instance: 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 5 th 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 wrong 26 > “#”
26 typically the developer mentioned the file as test ready in BT, but did not check the file in into the VS 31 SOFTWARE CONFIGURATION MANAGEMENT
Figure 5.5 Usage syntax of cvs_rcheck
Full: cvs _rcheck -d \ -x
\ -o
32 SOFTWARE CONFIGURATION MANAGEMENT
6 The conclusion
The thesis provided a reader with the terminology overview as well as introduction to the area, including example of inappropriate versioning system usage – to get an image of the problems. The project brought the specific solution – structured way described the approach of employing versioning system for the purposes of the release management, which succeeds in the mandatory prerequisites creation for successful release build, deployment and project internal/external delivery. The details level went to extend that just commands of a particular versioning system could deepen the information provided. The tools implemented provide the claimed functionality. Moreover, the tools developed by me within this master’s thesis project (as well as the set up approach) are being used now within one of the teams of the project which I joint in the year 2005 to support smooth and transparent deployment process (frequently into a testing environment). In the time when I rolled off the other teams were about to establish this approach as the team’s approach due to issues related to the deployment of a release (issues were caused by missing or inappropriate release management, software configuration management respectively). No issues encountered so far. This could be considered as proof of concept as well as of correctness of design and implementation. Possible improvements are for instance to tune the parameters and usage of frequently utilized UN*X command during the run, i.e. sed or grep . Extra focus can be put on removal of temporary files usage in appeared scope. I’ve started the implementation on the SUN Solaris 5.8 system, which mounts /tmp into the memory, thus no hard disk access slowdown. Linux uses regular hard disk area, so the disk access speed takes place. Fortunately the time of execution was not critical so far, maximum time experiences has been around 25 minutes for repository sized at 600MB, containing binary files as well. The disk was SCSI one, the machine Sun SunFire 440.
33 SOFTWARE CONFIGURATION MANAGEMENT
7 Literature and resources
[1] DPRICE, CVS, http://www.nongnu.org/cvs/ (May, 2006) [2] About CVS, http://ximbiot.com/cvs/ (May, 2006) [3] Price, Derek R., CVS v1.11.21 On Line Manual, http://ximbiot.com/cvs/manual/cvs 1.11.21/cvs.html , (May, 2006) [4] Tichy, Walter F., Purdue University, West Lafayette, IN, 47907. Manual Page Revision: 5.6; Release Date: 1995/06/05. Copyright © 1982, 1988, 1989 Walter F. Tichy. Copyright © 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert. The RCS Manual Page on line, http://www.die.net/doc/linux/man/man5/rcsfile.5.html , (May, 2006) [5] CvsGui features, WinCVS home web site, http://www.wincvs.org/ (May, 2006) [6] CVS & SCC, CVS SCC proxy plug in, http://www.pushok.com/soft_cvs_proxy.php (May, 2006) [7] Sobell, Mark G., Linux – Praktický průvodce Computer Press 1999, ISBN 80 7226 190 8 [8] Mehmet, Emre Can, Factory Assembly Test Execution, 2005
34 SOFTWARE CONFIGURATION MANAGEMENT
A Appendix
a. The cvs_rcheck script output
Figure A.1 The csv file content
STATUS;HEAD_REV;TO_TEST_REV;TO_RELEASE_REV;FILE_NAME +++-+;1.1;1.1.1.1;1.1.1.1;server/setup/README +++-#;1.1;1.1.1.1;1.1.1.1;server/setup/LICENCE +++++;1.2;1.2;1.1;server/setup/setup.conf ++++-;1.3;1.3;1.2;server/setup/setup.sh ----+;1.2;n/a;n/a;DP/test-input_params.sh ----+;1.2;n/a;n/a;DP/test-module_mapping.sh ----+;1.3;n/a;n/a;DP/mklabel ----+;1.6;n/a;n/a;DP/cvs_rcheck ----+;1.1;n/a;n/a;DP/R1_10_3-BT_list.txt ----+;1.1;n/a;n/a;DP/cvs_rcheck-module_exclude_list.txt ----+;1.1;n/a;n/a;DP/test-module_excluding.sh
Figure A.2 The xls file content STATUS HEAD TEST RELEASE FILE NAME +++-+ 1.1 1.1.1.1 1.1.1.1 server/setup/README +++-# 1.1 1.1.1.1 1.1.1.1 server/setup/LICENCE +++++ 1.2 1.2 1.1 server/setup/setup.conf ++++- 1.3 1.3 1.2 server/setup/setup.sh ----+ 1.2 n/a n/a DP/test-input_params.sh ----+ 1.2 n/a n/a DP/test-module_mapping.sh ----+ 1.6 n/a n/a DP/mklabel ----+ 1.6 n/a n/a DP/cvs_rcheck ----+ 1.1 n/a n/a DP/MLO_BE_V1_10_6_0-list.txt ----+ 1.2 n/a n/a DP/cvs_rcheck-module_exclude_list.txt ----+ 1.2 n/a n/a DP/test-module_excluding.sh The situation shown is the README file hasn’t been changed nor listed on the list of files to be promoted (list) [ok]; LICENCE file hasn’t been updated but mentioned on the list [nok]; file setup.conf has been modified in VS and present on the listlisted [ok]; setup.sh modified but not listed [nok]; all other files where never released as any release even never label as test ready
35 SOFTWARE CONFIGURATION MANAGEMENT b. An example of history graph of a file in VS repository
Figure A.3 Graphical CVS log
Figure shows an example of cvs graphical log representing all lebels applied in past, i.e. which revision has been released as which release. Example screenshot is taken from [5].
36 SOFTWARE CONFIGURATION MANAGEMENT c. The mklabel in action
Figure A.4 Saved output from the command shell while working with mklabel tool
[marek@agaue DP]$ ll drwxrwxr-x 2 marek marek 4096 May 15 21:09 CVS -rwxrwxr-x 1 marek marek 23847 May 15 20:43 cvs_rcheck -rw-rw-r-- 1 marek marek 125 Apr 20 01:53 cvs_rcheck- module_exclude_list.txt -rwxrwxr-x 1 marek marek 8335 May 15 20:49 mklabel -rw-rw-r-- 1 marek marek 9 Nov 17 00:06 V1_10_6_0-BT_list.txt -rwxr--r-- 1 marek marek 2244 Apr 13 00:24 test-input_params.sh -rwxr--r-- 1 marek marek 1260 Apr 20 00:50 test-module_excluding.sh -rwxr--r-- 1 marek marek 1777 Apr 12 23:39 test-module_mapping.sh -rwxrwxr-x 1 marek marek 953 May 15 21:04 test.sh [marek@agaue DP]$ cvs log test.sh RCS file: /usr/local/cvs_repo/DP/test.sh,v Working file: test.sh head: 1.1 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 1; selected revisions: 1 description: ------revision 1.1 date: 2005/11/22 23:49:24; author: marek; state: Exp; First checkin - a tool to test the approach(es), currently gawk vs UNIX awk test and getting the module mapping test ======[marek@agaue DP]$ ./mklabel test.sh mklabel (developer space) Head revision: 1.1 Repository revision: 1.1 Sticky revision: (none)
37 SOFTWARE CONFIGURATION MANAGEMENT Tagging... T test.sh File [test.sh] successfully labeled with tag TEST_READY [marek@agaue DP]$ cvs log test.sh RCS file: /usr/local/cvs_repo/DP/test.sh,v Working file: test.sh head: 1.1 branch: locks: strict access list: symbolic names: TEST_READY: 1.1 keyword substitution: kv total revisions: 1; selected revisions: 1 description: ------revision 1.1 date: 2005/11/22 23:49:24; author: marek; state: Exp; First checkin - a tool to test the approach(es), currently gawk vs UNIX awk test and getting the module mapping test ======[marek@agaue DP]$ echo "" >> test.sh [marek@agaue DP]$ cvs commit -m "dummy extra revision" test.sh Checking in test.sh; /usr/local/cvs_repo/DP/test.sh,v <-- test.sh new revision: 1.2; previous revision: 1.1 done [marek@agaue DP]$ cvs log test.sh RCS file: /usr/local/cvs_repo/DP/test.sh,v Working file: test.sh head: 1.2 branch: locks: strict access list: symbolic names: TEST_READY: 1.1 keyword substitution: kv total revisions: 2; selected revisions: 2
38 SOFTWARE CONFIGURATION MANAGEMENT description: ------revision 1.2 date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0 dummy extra revision ------revision 1.1 date: 2005/11/22 23:49:24; author: marek; state: Exp; First checkin - a tool to test the approach(es), currently gawk vs UNIX awk test and getting the module mapping test ======[marek@agaue DP]$ ./mklabel test.sh mklabel (developer space) Head revision: 1.2 Repository revision: 1.2 Sticky revision: (none) Tagging... T test.sh File [test.sh] successfully labeled with tag TEST_READY [marek@agaue DP]$ cvs log test.sh RCS file: /usr/local/cvs_repo/DP/test.sh,v Working file: test.sh head: 1.2 branch: locks: strict access list: symbolic names: TEST_READY: 1.2 keyword substitution: kv total revisions: 2; selected revisions: 2 description: ------revision 1.2 date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0 dummy extra revision ------revision 1.1 date: 2005/11/22 23:49:24; author: marek; state: Exp;
39 SOFTWARE CONFIGURATION MANAGEMENT First checkin - a tool to test the approach(es), currently gawk vs UNIX awk test and getting the module mapping test ======[marek@agaue DP]$ cvs update -r 1.1 test.sh U test.sh [marek@agaue DP]$ cvs log test.sh RCS file: /usr/local/cvs_repo/DP/test.sh,v Working file: test.sh head: 1.2 branch: locks: strict access list: symbolic names: TEST_READY: 1.2 keyword substitution: kv total revisions: 2; selected revisions: 2 description: ------revision 1.2 date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0 dummy extra revision ------revision 1.1 date: 2005/11/22 23:49:24; author: marek; state: Exp; First checkin - a tool to test the approach(es), currently gawk vs UNIX awk test and getting the module mapping test ======[marek@agaue DP]$ ./mklabel test.sh mklabel (developer space) Head revision: 1.2 Repository revision: 1.1 Sticky revision: 1.1 You are going to tag not the latest revision of file [test.sh]. Latest: 1.2/Current: 1.1 Are you sure? [y/n] y Tagging... T test.sh File [test.sh] successfully labeled with tag TEST_READY
40 SOFTWARE CONFIGURATION MANAGEMENT [marek@agaue DP]$ cvs log test.sh RCS file: /usr/local/cvs_repo/DP/test.sh,v Working file: test.sh head: 1.2 branch: locks: strict access list: symbolic names: TEST_READY: 1.1 keyword substitution: kv total revisions: 2; selected revisions: 2 description: ------revision 1.2 date: 2006/05/15 19:10:12; author: marek; state: Exp; lines: +1 -0 dummy extra revision ------revision 1.1 date: 2005/11/22 23:49:24; author: marek; state: Exp; First checkin - a tool to test the approach(es), currently gawk vs UNIX awk test and getting the module mapping test ======[marek@agaue DP]$ cvs tag -d TEST_READY test.sh D test.sh [marek@agaue DP]$ cvs admin -o 1.2 test.sh RCS file: /usr/local/cvs_repo/DP/test.sh,v deleting revision 1.2 done [marek@agaue DP]$ cvs log test.sh RCS file: /usr/local/cvs_repo/DP/test.sh,v Working file: test.sh head: 1.1 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 1; selected revisions: 1
41 SOFTWARE CONFIGURATION MANAGEMENT description: ------revision 1.1 date: 2005/11/22 23:49:24; author: marek; state: Exp; First checkin - a tool to test the approach(es), currently gawk vs UNIX awk test and getting the module mapping test ======
42