Robotic Tram Data Collection System Software … · Robotic Tram Data Collection System Software Configuration Management Plan Version 2.3 4/8/2008 . Software Configuration Management

Circular Logic

2008 Circular Logic

Robotic Tram Data Collection System Software Configuration Management Plan

Version 2.3 4/8/2008

Software Configuration Management Plan

SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

1

Document Control

Approval

The Guidance Team and the customer will approve this document.

Document Change Control

Initial Release: 1.0

Current Release: 2.3

Indicator of Last Page in Document: @

Date of Last Review: 1/25/08

Date of Next Review: 1/25/08

Target Date for Next Update: 1/25/08

Distribution List

This following list of people shall receive a copy of this document every time a new version of this document

becomes available:

Guidance Team Members: Dr. Ann Gates

Dr. Steve Roach

Ernesto Medina

Customer: Dr. Craig Tweedie

Santonu Goswami

Software Team Members: Luis A. Garcia

Erik Madrid

Brandon Marin

Javier Martinez

Alfredo Saenz

Change Summary

The following table details changes made between versions of this document

Version Date Modifier Description

1.0 1/15/08 Erik Madrid Initial setup – created distribution list,

document change control, added the title,

rough draft of introduction, referenced work

1.1 1/17/08 Erik Madrid

Brandon Marin

Creation of sections 2.1 and 2.2

1.2 1/23/08 Javier Martinez Creation of section 3.1

1.3 1/23/08 Brandon Marin Creation of section 3.2 & Change Request

form

1.4 1/23/08 Luis A. Garcia Modification of section 2.2 – revised labeling

similarly to MSDN standards

1.5 1/23/08 Erik Madrid Creation of section 3.3

Creation of Tortoise SVN tutorial

Modification of section 3.1 to comply with

content from template

Modification of section 2.2 – created backup

plan


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

2

Modification of 2.1 to comply with template

content

1.6 1/24/08 Alfredo Saenz Creation of section 4

1.7 1/24/08 Javier Martinez

Alfredo Saenz

Modification of section 4 according to

guidelines given during the meeting

1.7 1/24/08 Luis A. Garcia Modification of section 4 to comply with

content from template

Editing of sections 2.1, 3.1, 3.2, 3.3

1.8 1/24/08 Brandon Marin Modification of section 1 to include purpose

and intended audience

Modification of section 3.2 to changed

discussed in meeting

Editing of sections 2.1, 2.2, 3.3

1.9 1/24/08 Erik Madrid Initial formatting – verified document

complies with APA standards

2.0 1/24/08 Brandon Modification of formatting to include

appendices and images

Modification to all sections – wrote

introductions to all sections

2.1 1/25/08 Erik Madrid Completion of 1st draft

2.2 1/25/08 Luis A. Garcia Reviewed version 2.1 for spelling grammar

and content

2.3 1/25/08 Erik Madrid

Brandon Marin

Luis A. Garcia

Javier Martinez

Modification to flow chart to include changes

Final walkthrough edited document for

grammar, spelling, and content.


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

3

TABLE OF CONTENTS

DOCUMENT CONTROL ............................................................................................................................ 1

APPROVAL .................................................................................................................................................. 1 DOCUMENT CHANGE CONTROL ................................................................................................................ 1 DISTRIBUTION LIST .................................................................................................................................... 1 CHANGE SUMMARY .................................................................................................................................... 1

1. INTRODUCTION ................................................................................................................................. 5

1.1. PURPOSE AND INTENDED AUDIENCE ............................................................................................. 5 1.2. OVERVIEW ...................................................................................................................................... 5 1.3. REFERENCES .................................................................................................................................. 5

2. SOFTWARE CONFIGURATION IDENTIFICATION .................................................................... 5

2.1. SOFTWARE CONFIGURATION ITEM IDENTIFICATION ................................................................... 5 2.2. SOFTWARE CONFIGURATION ITEM ORGANIZATION .................................................................... 6

3. SOFTWARE CONFIGURATION CONTROL ................................................................................. 7

3.1. DOCUMENTATION........................................................................................................................... 7 3.2. CONFIGURATION CONTROL BOARD .............................................................................................. 8 3.3. PROCEDURES .................................................................................................................................. 8

4. SOFTWARE CONFIGURATION AUDITING ................................................................................. 9

5. APPENDIX .......................................................................................................................................... 11

5.1. CHANGE REQUEST FORM ............................................................................................................ 11 5.2. TORTOISE SVN TUTORIAL .......................................................................................................... 13 5.2.1. Checking Out a Repository .................................................................................................... 13 5.2.2. Locking a Directory or Document in the Repository ............................................................. 18 5.2.3. Updating the Repository ........................................................................................................ 21 5.2.4. Committing Changes to the Repository ................................................................................. 23 5.2.5. Adding a File or Directory to the Repository ........................................................................ 25 5.2.6. Removing a File or Directory from the Repository ............................................................... 28 5.3. CHANGE REQUEST FLOW CHART................................................................................................ 30


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

4

FIGURES

Figure 1 SVN Checkout Option ........................................................................................................................... 13 Figure 2 Checkout Dialog .................................................................................................................................... 14 Figure 3 Server Certificate Prompt ....................................................................................................................... 15 Figure 4 Password Prompt .................................................................................................................................... 16 Figure 5 Checkout Status and Confirmation Dialog ............................................................................................. 17 Figure 6 Get Lock Option ..................................................................................................................................... 18 Figure 7 Lock Files Message Dialog .................................................................................................................... 19 Figure 8 Lock Finished Dialog ............................................................................................................................. 20 Figure 9 SVN Update Option ............................................................................................................................... 21 Figure 10 Update Summary Dialog ...................................................................................................................... 22 Figure 11 Commit Option .................................................................................................................................... 23 Figure 12 Enter Log Message Dialog ................................................................................................................... 24 Figure 13 Add Option ........................................................................................................................................... 25 Figure 14 Add Confirmation Dialog .................................................................................................................... 26 Figure 15 Add Information Dialog ....................................................................................................................... 27 Figure 16 Delete Option ....................................................................................................................................... 28 Figure 17 Change Request Form Evaluation ........................................................................................................ 30


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

5

1. Introduction

“Robotic Tram Data Collection System” (RTDCS) is a project aimed at collecting, storing, displaying,

and analyzing data measured in the Barrow Environmental Observatory.[1] The configuration management

plan (CMP) establishes a configuration management (CM) approach that maintains the integrity of the RTDCS

project and provides traceability for changes incorporated into the project. The CM process defines the

technical and administrative actions for identifying the functional, performance, and physical characteristics of

configuration items and controls the changes to those characteristics.

1.1. Purpose and Intended Audience The purpose of a software CMP is to control the system differences and changes in the development

process to minimize risk and error.[2] CMP is essential for a project in which many users contribute to its life

cycle. It minimizes complexity by enabling the controlled management of configuration items as they evolve in

all stages of development and maintenance. CM implements a process in which the development team

identifies, communicates, implements, documents, and manages changes in the project. The CMP helps to

maintain the integrity of the items that have been placed under its control. This will assure developers that they

will be involved in the change process. CM will facilitate and ensure that appropriate communications occur

among all developers. This guarantees that each developer has input on the overall scope of the project. This

document is intended for persons involved in the development of this project.

1.2. Overview

The CMP contains three core sections: Software Configuration Identification, Software Configuration

Control, and Software Configuration Auditing. The software configuration identification section identifies all

entities that will change throughout the life of the project. This section also defines a naming convention

paradigm for version control and describes the directory structure of the database. The software configuration

control section defines rules and procedures for preparing, evaluating, and approving or disapproving all

changes to the configuration items throughout the life cycle.[3] This section includes procedures on

documenting, evaluating, and managing changes to the system configuration. The software configuration

auditing section defines a mechanism for maintaining consistency and history of versions and variants.[3] This

section outlines the procedures for examining the correctness and accuracy of the system configuration.

1.3. References [1] Logic, Circular. Feasibility Report. El Paso : UTEP SE, 2007.

[2] Pfleeger, S. & Atlee, J.M. Software Engineering Theory and Practice . s.l. : Prentice Hall, 2006.

[3] Gates, Ann & Roach, S. Software Configuration Management Plan. [Microsoft Power Point] EL Paso :

s.n., 2008.

[4] MSDN. .NET Framework Developer Center. [Online] Microsoft. http://msdn2.microsoft.com/en-

us/library/system.version.aspx.

2. Software Configuration Identification

2.1. Software Configuration Item Identification To ensure that guidelines of configuration management are adhered to, the system configuration will be

comprised of the following components:


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

6

Source code

Test Suites

Graphical User Interface

Configuration Management Document (CFG)

Software Code Inspection Document

Software Design Document (SDD)

Meeting Records*

System Requirements Specification Document (SRS)*

Any modifications to these documents will employ the mechanisms described in section 3 of this document.

*Document will be located in the repository for reference only

2.2. Software Configuration Item Organization Baselines and updates to baselines for the various items that are managed, in particular code, will

adhere to the following versioning convention which is a slight modification on the system used by the Version

class found in the .NET platform: major.minor[.build]. [4]

Major – Items with the same name but a different major version are not interchangeable. This would

be appropriate where backwards compatibility is not assumed. For example, versions 1.1 and 2.0 of component

A would not be interchangeable. The major number would increment, for example, when a component’s API

changes.

Minor – When the major number and name are the same for a particular item and the minor is

different, this indicates significant enhancement with backwards compatibility intended. . For example,

versions 1.1 and 1.4 of component A would be interchangeable. This increment would be suitable for when the

API of a component remains the same and only the internal implementation of a method changes.

Build – This is an optional number that represents a recompilation of the same source code. For

example, if a different version of a tool was used to compile the code the build number would be appended to

the version number.

Configuration management will transpire through a Subversion (SVN) control repository that will

reside on the software engineering class server located at http://repository.cs.utep.edu/svn/sefall2. SVN serves

as a repository management tool that is compatible with both Microsoft Windows and Posix based operating

systems. In order to use SVN and contribute to a repository, the developers must download an SVN client.

Tortoise SVN is an SVN client shell extension for Microsoft Windows, which is available at

http://tortoisesvn.net/downloads. The developers will use version 1.4.7 of Tortoise SVN, which is the most

current version available. Tigris maintains a SVN client that is applicable on most Posix based operating

systems (e.g. Linux and Unix). The developers will use version 1.4.6 of Tigris’ Linux Subversion client. If

Tigris releases a new version of either Tortoise SVN or the Subversion client for Linux, the configuration

control board (CCB) will decide whether the developers will adopt the new release. Appendix 5.2 contains a

general tutorial on how to use Tortoise SVN.

The root directory will contain three child directories: Archive, Project, and Documents. The Archive

directory will contain a Document Archive directory and a Project Archive directory. After each new baseline,

any previously related item will be copied and placed into the respected archive directory with the appropriate

label. The Documents directory will contain the documents listed in section 2.1. Each document will reside in

a directory with that Document’s title. For example, the SRS will reside in /Documents/SRS/.

A backup scheme will protect all files in the system configuration from loss or potential data

corruption. A backup can consist of the one of the following: full or incremental. A full backup will back up

all files in the repository. A full backup will be performed automatically every week on Sunday at midnight

Mountain Standard Time (MST). An incremental backup is a type of backup that only backs up files that have

changed since any incremental or full backup. A daily incremental backup will be performed automatically at

midnight MST. The person designated as the lead of a deliverable will be responsible for ensuring that the

backup plan is operating normally. In the event that the repository needs recovering, Erik Madrid will be in

http://tortoisesvn.net/downloads


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

7

charge of restoring any file that is lost or corrupted. Microsoft Window’s backup application will perform the

scheduled backups. It will compress the backup file, which will reside on the “sefall2” computer in the SE lab.

SVN will allow multiple developers the ability to work in parallel on the system at any given point in

time (see section 3.3 for specific access and modification protocols). SVN allows users to check-out the most

recent version of a system configuration. The developers can then work on the system without affecting the

work of other’s. When the developer has finished making changes to the system, he/she can commit his/her

changes. When changes are committed, SVN alerts the user if he/she has a configuration that is inconsistent

with the most recent version in the repository. The user can then decide if he/she wants to either merge the

changes or perform a comparison against the version on the repository. Once the user commits the changes,

SVN updates the release number of all files with a new release number.

3. Software Configuration Control

3.1. Documentation All changes to items that will be inherent in the repository will be documented in the form of a Change

Request form. This form will act as a record containing the information that defines a proposed change to a

software system. This documentation will make the tracking of manipulated changes more coherent to the CCB

and will allow for more control to the changes made to the software system. A change to the system

configuration is defined as any modification to any item that changes the state of the system configuration. In

particular, a change to the source code is defined to be any change that affects the performance or functionality

of the software system.

A change request can be initiated by a developer or the CCB. The Change Request form will contain

the following fields to be filled out by the developers:

Request Number,

Request Date,

Request Title,

Originator’s Name,

Originator’s Phone/Email,

Priority,

Assigned To,

Start Date,

Delivery Date,

Request Description,

Justification,

Alternative Solutions,

Impact Assessment,

Recommendation,

Authorization.

The Request Number field will contain a numerical value related to the occurrence of the incident.

The Request Date field will contain the date the developer or the configuration management board initiated the

request. The Request Title field will contain a descriptive title for the change request. The Originator’s Name

field will contain the name of the developer or party that initiated the request. The Originator’s Phone/Email

will contain the developer’s respective contact information. The Priority field will contain a designation of

either Routine or Urgent. The Assigned To field will contain the name of the developer responsible for

executing the change. The Start Date field will contain the date the developer is to commence the change. The

Delivery Date field will contain the date the developer is expected to complete the change. The Request

Description field will contain a detailed description of the request change. The Justification field will contain a

reason as to why the originator requested the change. The Alternative Solutions field will contain options to the

proposed change. The Impact Assessment field will outline all components in the system configuration that the


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

8

change will affect. The Recommendation field will contain the CCB’s final decision on the proposed change.

The Authorization field will contain the signatures of all members present in the recommendation. Appendix

5.1 contains the CR template.

3.2. Configuration Control Board Configuration control is the process for tracking and managing system and subsystem changes. To ensure

the integrity of the configuration control process, Circular Logic will establish the aforementioned CCB to

evaluate and authorize the changes to the system configuration. The board’s primary roles are to:

assess the impact and desirability of proposed changes,

authorize the establishment of project baselines and identification of configuration items,

review and authorize changes to project baselines,

monitor changes and updates to project requirements as part of CM and

approve the creation of deliverables into the project’s baseline directory.

The body of the board will consist of the entire development team. Two distinct tiers will make up the

CCB. The first tier holds the position of CCB manager. The project leader of the current task holds this

position. The manager has the approval power of the board’s responsibilities. The second tier holds the

remaining members of the development team. The members of this tier may vote to override the CCB

manager’s decision. A majority vote is required to override the CCB manager. If a split decision occurs,

between the second tier and the first tier, the guidance team will decide the approval.

The CCB reviews and determines the disposition of all requests to change the items that are under its

control (code, documentation, and data). A change request is the only mechanism for initiating changes to the

system configuration. The change process starts by the submission of a change request to the CCB manager.

After the manager reviews and logs the change, the manager distributes copies of the document to remaining

members of the CCB prior to the next meeting. The exception to the above statement is that the change request

originator has marked the change request as URGENT. The manager will take into consideration its immediate

operational impact and will either approve or reduce its priority to ROUTINE. If the priority is reduced, the

CCB will review the document during their next meeting. At a CCB meeting, the CCB evaluates the request

and determines the approval of the change request. The CCB determines approval by the following factors:

the functional aspect of the change (i.e., the consequences of not implementing the change and the

complexity of the change),

current phase of the project,

possible alternatives to the proposed change,

resources required to implement the change,

documentation requirements,

integration and testing requirements and

the effects on other processing and interface of other agencies.

Once the decision of the CCB is made, the appropriate actions are taken to facilitate the change. The

details of these actions are defined in section 3.3.

3.3. Procedures Subversion will control all the configuration items in the repository outlined in section 2.1. At the

beginning of the development phase, each developer will checkout the baseline repository. When the CCB

decides a developer is to change a component of the system configuration, that developer will have exclusive

access to that component and any dependent of that component. First, the developer will update the repository

(to ensure that he/she has the current version) and lock that component. Locking a component ensures that

other developers cannot interfere with the change. The developer will then describe the reason for placing a

lock on the component by entering a message in the “message” dialog provided by the Subversion client. The

conditions for releasing the lock on the section are the following:


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

9

If the configuration item is a configuration document, a technical review has been made and the CCB

has approved the document as a final version;

If the configuration item is source code:

o the source code will compile without error,

o the developer will have written test cases for all modified portions of the source code,

o the source code will have passed all unit or regression testing and

o any appropriate documentation changes have been made.

Only after the change meets these requirements and the CCB has approved the results of the change

will the developer release the lock on the component. Upon release, the developer will commit his/her changes

by performing an SVN commit. The developer will log changes by entering a message in the “message” dialog

provided by the Subversion client.

If, for any reason, a member of the team feels that a document should be reverted to a previous version,

the CCB will consider the request and decide whether the reversion is necessary. This will be done by

performing a revert action provided by the Subversion client. The developer reverting the document(s) will log

the reason for reverting by entering a message in the “message” dialog provided by the Subversion client.

The person responsible for enforcing these guidelines will be the person designated as the lead on the

project task. This person will be responsible for ensuring:

each assigned component is locked,

the developers meet the guidelines of releasing a lock on a component and

the developers correctly log changes in the SVN client.

This person will also be responsible for bringing any discrepancies to the attention of the CCB.

The process for instantiating a new version will adhere to the following:

the CCB has approved the change,

the developer will create the needed directories and/or files,

the developer will lock the newly instantiated component,

upon completion, the developer will unlock the component,

the developer will commit the change and

the developer will document the additions in the appropriate SVN log.

4. Software Configuration Auditing

This document has described the software configuration plan that will be employed throughout

development of the software. This section describes the auditing process that will be followed to ensure that the

standards described in the rest of this document are followed and that a consistency is maintained during

development.

The configuration auditing board (CAB) will consist of two members assigned by the CCB manager.

These members have the responsibility of reviewing the CCB change request decisions and the appropriate

documentation of those decisions. Once the CCB has reached a decision regarding a change request form, the

CAB will perform an audit. An audit consists of:

ensuring the necessary documentation has been made and filed,

determine if the decision of the board is correct from the documentation on file and

create an audit report.

The audit report will address the following questions:

did the CCB follow the guidelines set by the CMP


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

10

have the CCB recorded the necessary documents for accepting or rejecting a change report

has all the configuration item been properly integrated into the project

Through these audit reports, the development team can be assured that development policies are

adhered to and that the process of making changes and reviewing these changes is a formal one.


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

11

5. Appendix

5.1. Change Request Form


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

12


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

13

5.2. Tortoise SVN Tutorial

5.2.1. Checking Out a Repository

In a newly created directory (e.g., “folder”), right-click inside the folder. A menu will emerge. Click on the

SVN Checkout… option (see Fig.1)

Figure 1 SVN Checkout Option


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

14

A “Checkout” dialog will emerge. Enter the path of the repository into the “URL of repository:” text field in

the Checkout dialog (see Fig. 2) and click on Ok.

Figure 2 Checkout Dialog


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

15

Tortoise SVN will prompt you to accept a server certificate (see Fig. 3) because this is the first time you

checkout this repository. It is recommended that you accept this certificate permanently.

Figure 3 Server Certificate Prompt

(Courtesy of http://www.openkore.com/images/svn/cert.png)


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

16

Next, Tortoise SVN will prompt you to enter the repository password (see Fig. 4). Enter the username and

password and click on Ok. Be sure to check the save permanently option or Tortoise SVN will prompt you to

enter a username and password each time you perform a Subversion task

Figure 4 Password Prompt

(Courtesy of http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/images/Authenticate.png)


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

17

If you did everything correctly, Tortoise SVN will display a dialog indicating which files it is copying to your

local computer. Click on Ok to close the dialog. (see Fig. 5).

Figure 5 Checkout Status and Confirmation Dialog

Congratulations! Now you have successfully checked out the repository. You can now begin to modify any

document that is not locked or does not have elevated privileges.


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

18

5.2.2. Locking a Directory or Document in the Repository

“Locking” a file or directory in your repository can be a useful tool when you want to ensure that no one

interferes with what you are working on.

First, right click on the file or directory that you wish to lock. A menu will emerge. Select the “Tortoise SVN”

sub-menu. Now, select the “Get Lock…” option (see Fig. 6).

Figure 6 Get Lock Option


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

19

Next, a “Lock Files” dialog will appear (see Fig.7). Enter a message as to why you are locking the files and

click on Ok.

Figure 7 Lock Files Message Dialog


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

20

A “Lock Finished!” dialog will appear illustrating a summary of the locked files (see Fig. 8). To close the

dialog, click on Ok.

Figure 8 Lock Finished Dialog


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

21

5.2.3. Updating the Repository

Before you work on a repository, it is a good idea to update it to ensure that you have the latest revision of all

the files stored on SVN server.

To update the repository, go to the directory that you wish to update and right click in the folder. A menu will

emerge (see Fig. 9). Click on “SVN Update”.

Figure 9 SVN Update Option


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

22

A dialog will emerge illustrating a summary of the updated documents(see Fig. 10). If the files you contain are

up-to-date, the summary will not contain any files. Click on Ok to close the dialog

Figure 10 Update Summary Dialog


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

23

5.2.4. Committing Changes to the Repository

Performing a commit will merge your changes to the repository.

To commit your changes, right-click on the folder or a file that you wish to commit and a menu will emerge

(see Fig. 11). Select the “SVN Commit” option.

Figure 11 Commit Option


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

24

An “Enter Log Message” dialog will emerge (see Fig. 12). Enter a detailed message as to why you are

committing your changes.

Figure 12 Enter Log Message Dialog


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

25

5.2.5. Adding a File or Directory to the Repository

To add a file or directory to the repository, right-click on the file or directory. A menu will emerge (see Fig.

13). Select the “Tortoise SVN” submenu. Now, select the “Add…” option.

Figure 13 Add Option


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

26

An “Add” confirmation dialog will emerge that illustrates the file(s) and/or directories that Tortoise SVN

should add (see Fig.14). Verify you have selected the proper files. To apply the changes, click on Ok.

Figure 14 Add Confirmation Dialog


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

27

Finally, an information dialog will emerge indicating which items(s) was/were added (see Fig. 15). To close

this dialog, click on the Ok button. Now the file is in the repository for other developers to view and modify.

Remember that all other developers must perform an “Update” in order to receive the item(s).

Figure 15 Add Information Dialog


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

28

5.2.6. Removing a File or Directory from the Repository

To remove a file or directory from the repository, right-click on the file or directory. A menu will emerge (see

Fig. 16). Select the “Tortoise SVN” submenu. Now, select the “Delete” option.

Figure 16 Delete Option


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

29

Next, Tortoise SVN will delete the item(s) from your directory.

Finally, perform a SVN commit in order for your changes to take effect. Remember that other developers will

have to update their working copies of the repository for your changes to be seen on their copies of the

repository.


SCM

Circular Logic Date

4/8/2008 2:08 PM

Page

30

5.3. Change Request Flow Chart

Figure 17 Change Request Form Evaluation

@