robotic tram data collection system software … · robotic tram data collection system software...
Post on 25-Sep-2018
229 Views
Preview:
TRANSCRIPT
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
Software Configuration Management 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.
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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:
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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:
Software Configuration Management Plan
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
Software Configuration Management Plan
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.
Software Configuration Management Plan
SCM
Circular Logic Date
4/8/2008 2:08 PM
Page
11
5. Appendix
5.1. Change Request Form
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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)
Software Configuration Management Plan
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)
Software Configuration Management Plan
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.
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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
Software Configuration Management Plan
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.
top related