Secure Digital Archiving
A SOFTWARE ENGINEERING PROJECT (2R690)
at the
EINDHOVEN UNIVERSITY OF TECHNOLOGY
during
2001-2002
by
SOFTWARE CONFIGURATION
MANAGEMENT PLAN
VERSION 1-0-0
Secure Digital Archiving – Software Configuration Management Plan – Page 2
A ABSTRACT
This document is one of four management documents produced for one of seven
projects for the course called ‘Software engineering’ (2R690) at the Eindhoven
University of Technology.
This document contains the rules and guidelines for writing of all the documents for
this project. Furthermore it contains procedures for document versioning,
nomenclature and storage on a central computer system. And finally it describes the
backup- and safety procedure for minimization of the risk that documents get lost in
case of a system failure.
The document complies with the Software Configuration Management Plan (SCMP)
from the Software Engineering standard as it is formulated by the European Space
Agency [ESA].
Secure Digital Archiving – Software Configuration Management Plan – Page 3
B TABLE OF CONTENTS
A ABSTRACT _____________________________________________________2
B TABLE OF CONTENTS ___________________________________________3
C DOCUMENT STATUS SHEET______________________________________5
D DOCUMENT CHANGE RECORD ___________________________________6
1 INTRODUCTION_________________________________________________7
1.1 Purpose _____________________________________________________7
1.2 Scope _______________________________________________________7
1.3 Definition, acronyms and abbreviations ____________________________7
1.4 References ___________________________________________________8
2 MANAGEMENT _________________________________________________9
2.1 Organization _________________________________________________9
2.2 Responsibilities _______________________________________________9
2.3 Interface management __________________________________________9
2.4 SCMP implementation _________________________________________9
2.5 Applicable procedures__________________________________________9
2.5.1 Templates _______________________________________________9
2.5.2 Document layout _________________________________________10
2.5.3 Custom styles ___________________________________________11
3 CONFIGURATION IDENTIFICATION ______________________________12
3.1 Naming conventions __________________________________________12
3.1.1 General ________________________________________________12
3.1.2 Version tags_____________________________________________12
3.2 Baselines ___________________________________________________13
4 CONFIGURATION CONTROL ____________________________________14
4.1 Library control_______________________________________________14
4.1.1 Development library ______________________________________14
4.1.2 Master library ___________________________________________15
4.1.3 Archive library __________________________________________15
4.2 Media control _______________________________________________15
4.2.1 Backup creation__________________________________________15
4.2.2 Backup restoration________________________________________16
4.3 Change control ______________________________________________16
4.3.1 Development library ______________________________________16
4.3.2 Master library ___________________________________________16
4.3.3 Archive library __________________________________________17
5 STATUS ACCOUNTING _________________________________________18
6 TOOLS, TECHNIQUES AND METHODS____________________________19
6.1 FTP _______________________________________________________19
6.2 Change control with CVS ______________________________________19
6.2.1 Modules________________________________________________19
6.2.2 Working with CVS _______________________________________19
6.3 Access control _______________________________________________20
7 SUPPLIER CONTROL____________________________________________21
8 RECORDS, COLLECTION AND RETENTION _______________________22
8.1 Management and product documents _____________________________22
Secure Digital Archiving – Software Configuration Management Plan – Page 4
8.2 Other documents _____________________________________________22
APPENDICES_______________________________________________________23
A SR PHASE _____________________________________________________23
B AD PHASE _____________________________________________________23
C CODE PHASE __________________________________________________23
D CVS COMMANDS _________________________________________________23
Secure Digital Archiving – Software Configuration Management Plan – Page 5
C DOCUMENT STATUS SHEET
Document name Software Configuration Management Plan
Document location SCMP/
Author(s) J van der Wulp, G Dorssers
Version 1-0-0
Status draft / internally accepted / conditionally approved / approved
Version Date Author(s) Summary
0-0-1 04-01-2002 J van der Wulp document creation
0-1-0 03-02-2002 J van der Wulp revision after interval review
0-1-1 17-02-2002 J van der Wulp Small change in development library
structure, addition of appendix B
0-1-2 01-05-2002 J van der Wulp Revisions for new project phase
1-0-0 10-06-2002 G Dorssers Added CVS Commands Appendix;
Changed status to Approved
Secure Digital Archiving – Software Configuration Management Plan – Page 6
D DOCUMENT CHANGE RECORD
Document title Software Configuration Management Plan
Document identification DevelopmentLibrary/Documents/Management/SCMP/
Page Paragraph Changes
6 D Changed structure of Document Change record, to reflect ESA
standard
8 1.4 Added [DDD] to the list of references
14 4.1.1 Small modifications in the structure of the development library
23 Appendix B/C Added tools used in the AD/Code phases
23 Appendix D Added some elementary CVS commands
Secure Digital Archiving – Software Configuration Management Plan – Page 7
1 INTRODUCTION
1.1 Purpose
The purpose of this document is to provide rules and guidelines for the storage and of
all documents that are created during this project. Additionally it will give naming and
layout conventions for all documents and describe the identification of all major
documents.
1.2 Scope
5 Configuration management activities:
• Construct a listing of all documents that need to be written during the project.
• Defining naming conventions for all project documents.
• Defining document layout conventions to ensure all documents have a uniform
appearance.
10 • Defining a structured way for document storage and versioning.
• Governing access rights of all project members to project documents.
• Ensuring all project documents conform the to the conventions defined in this
document.
• Safekeeping of all produced documents.
15
All Configuration Item’s (CI) that will be created during the project:
• SCMP: Software Configuration Management Plan
• SPMP: Software Project Management Plan
• SQAP: Software Quality Assurance Plan
20 • SVVP: Software Validation and Verification Plan
• ADD: Architectural Design Document
• ATP Acceptance Test Plan
• DDD: Detailed Design Document
• SRD: Software Requirements Document
25 • STD: Software Transfer Document
• SUM: Software User Manual
• URD: User Requirements Document
• Source code
• Miscellaneous documents (Consists of research documents, templates and
30 tools)
1.3 Definition, acronyms and abbreviations
2R690 The Software Engineering course at the Eindhoven
University of Technology
CI Configuration Item (document that is considered a single
entity)
CM Configuration Manager
CVS Concurrent Versions System
ESA European Space Agency
OpenBSD Secure Unix based operating system
Secure Digital Archiving – Software Configuration Management Plan – Page 8
SCMP Software Configuration Management Plan
SCP Secure Copy Program (file copy over SSH)
SQAP Software Quality Assurance Plan
SVVP Software Verification and Validation Plan
1.4 References
[ESA] ESA Software Engineering Standards, ESA PSS-05-02,
Issue March 1995,
ESA Board of Software Standardization and Control (BSSC),
ISBN 0-13-106568-8.
[DDD] Detailed Design Document of the SDA project,
Location: DDD/
[SQAP] Software Quality Assurance Plan of the SDA project,
Kees van der Sluijs, Richard Peters
Location: SQAP/
[SVVP] Software Verification and Validation Plan of the SDA project,
Kees van der Sluijs
Location: SVVP/
[SPMP] Software Project Management Plan of the SDA project,
Loek Simons
Location: SPMP/
Secure Digital Archiving – Software Configuration Management Plan – Page 9
2 MANAGEMENT
2.1 Organization
The persons that are directly involved in the Configuration Management are:
• Jeroen van der Wulp as Configuration Manager (CM)
• Guido Dorssers as vice Configuration Manager.
2.2 Responsibilities
35 The CM is mainly responsible for the uniformity of all CI’s. In order to achieve this
purpose the CM must define standards for all document types that have to be
produced for the project. It is also the task of the CM to construct templates to
simplify the document creation for authors. Because the necessary knowledge of some
programs used in this project might not be available by neither the CM nor the vice
40 CM, other group members can also be asked to create templates.
The vice CM is responsible for maintaining the production machine that runs the
environment that is required for the product to be made.
45 Both the CM and vice CM are responsible for:
• the central document storage
• availability for tools and documents to all project members.
• creating regular backups.
• the well functioning of the computer facilities that are made available to the
50 project group.
2.3 Interface management
In case failure of any hardware supplied by the University the CM or vice CM will
contact ‘Bureau Computer Faciliteiten’ (BCF), as they are assumed to have expert
knowledge of the hardware configuration of the supplied hardware.
2.4 SCMP implementation
Contrary to [ESA] there won’t be any new versions of this document for the following
55 phases in the project. Instead the SCMP will be updated with appendices for every
phase of the project. For more information concerning the planning of the SCMP
implementation, refer to the [SPMP, section 1.1].
2.5 Applicable procedures
All documents are subject to the standards described in [ESA]. This implies that all
documents that are produced during this project also have to adhere to the
60 requirements described in [SVVP] and [SQAP].
2.5.1 Templates
For all documents that are created in Microsoft Word there is a template--created and
maintained by Ronald Kruidhof--that must be used to construct any text document
(except for source code documents).
Secure Digital Archiving – Software Configuration Management Plan – Page 10
65 The template is available from the CVS repository (for CVS see section 4 of this
document).
The path from the root of the repository: ‘/Miscellaneous/Templates/SDA document
template.dot’
70 Note that the directory ‘Templates’ is defined as module, which means that the
template directory can be retrieved from CVS as a single directory.
2.5.2 Document layout
Each document must contain a title page that consists of the following items (from top
to bottom):
• The name of the project (Case Sensitive), thus ‘Secure Digital Archiving’
75 • Some general information: Such as the name of the course, and the span of the
project
• The group logo
• The name of the document (in Uppercase)
• The version tag of the document (version tags are explained in section 3.1.2)
80 The second page of each document holds a section called ‘ABSTRACT’ and contains
a short summary explaining the documents purpose.
The table of contents starts on the third page. It must be generated as to avoid
incorrect references in the table of contents.
85 The page directly following the table of contents contains the document status table,
which consists out of:
• The name of the document
• The location of the document specified as CVS module, or otherwise relative
to the CVS root. (In the former situation name must not be preceded by a slash
90 (‘/’) and in the latter situation it must be preceded by a slash.)
• The author(s) of the document
• The version tag
• The status of the document indicated by making the applicable value bold out
of the given list of values:
95 o Draft: The document has not been approved neither internally nor
externally.
o Internally accepted: The document has been internally approved.
o Conditionally approved: The document will be approved once all (on a
review) proposed changes have been carried out. No new review is
100 necessary.
o Approved: The document has been externally approved.
• And finally the table that holds the changes between all existing versions of
the document. This table holds per version of the document: the author, the
date and a summary of all changes
105 The page directly following the document status table contains the document change
record. This record contains all information regarding the latest modifications on the
document. It contains:
• The title of the document
• Document identification (location in the repository)
Secure Digital Archiving – Software Configuration Management Plan – Page 11
110 • The page(s) involved in the document change
• The section(s) involved in the document change
• Reason for change(s)
After the document change record the actual document content starts. For the
document content all lines (excluding the titles of sections/subsections) are numbered.
115 The layout described in this subsection is put in the Microsoft Word template referred
to in the previous section.
2.5.3 Custom styles
The Word template uses the standard Word names for describing the styles available
for all documents. If no custom style is available for some task then the default Word
styles must be used.
120 Additional comments on the style of documents:
• All titles of sections are made up out of uppercase characters only
• All titles of subsections are made up out of a single uppercase character
preceding lowercase characters
• All documents must be written in US-English
125 • Each new section starts on a new page
• Italic text may be used for accompanying figures charts or tables
• All documents are created using the Word template
• Extra emphasis on words is expressed by making that word bold
• References to other documents are written as: [REFNAME,SECTION] where
130 REFNAME is the name of the document that is referred to; SECTION is an
optional parameter indicating the section that is referred to
• The paper size of all documents must be A4
Secure Digital Archiving – Software Configuration Management Plan – Page 12
3 CONFIGURATION IDENTIFICATION
3.1 Naming conventions
3.1.1 General
All documents should be named according to the following scheme:
• All management and product documents have to be named according to their
135 respective abbreviation. Additionally a version number will be included in the
name. The format of the version tag will be described separately in section 3.2.
A template such documents:
[document name]-[version tag].[file type extension]
140
• All source code documents must have short clear names, which somehow
reflect the functionality that is embedded in the code. Note that there aren’t
any version-numbers included in the names of these documents. The reason
for this is that we want to make use of the Concurrent Versions System (CVS)
145 for keeping the versions of source code documents.
• Research-reports have to be named by the subject that was researched. Version
numbers or date information is not considered needed as these documents are
for internal use only, and authors can make changes to these documents as
they see fit.
150 • All internal documents, such as memos and notes, can be named as the creator
sees fit. Though they must have a short, reasonably clear and straightforward
name that is appropriate for the contents of such a document. And additionally
the name should contain the date of creation. A template for the name of such
a document:
155
YY-MM-DD-[document name].[file type extension]
3.1.2 Version tags
Each version tag consists of three fields, which each make up a version number,
separated by hyphens. Each field contains a version number that records documents
changes in response of one of three events. From now on we will refer to the
160 representation of the fields as event versions. These three events consist of ‘external
reviews’, ‘internal reviews’ and ‘informal reviews’ of the document. In which
informal reviews represent the communication between all authors of the document to
incorporate changes that need to be made to the document. Typically the informal
review version represents the work version of a document.
A template for a version tag:
165 [external review version]-[internal review version]-[informal review version]
Initially each document version tag will be set to ‘0-0-1’ indicating that no internal or
external reviews have lead to any changes in the document. For changes after any
event all fields to the right of the field that represented the event version are reset to
zero. Note that each event can only increase its respective field by one at a time.
Secure Digital Archiving – Software Configuration Management Plan – Page 13
3.2 Baselines
170 Baselines are documents that have been externally reviewed and approved. They will
be stored in the Master library (which will be discussed in section 4.1.2).
According to the [ESA] standard new versions of the management documents need to
be created for every stage in the project. Because of the small scale of this project, the
175 organization of (2R690) has decided that the same management documents are used
during the course of the project. Information specific for a stage in the project will be
added to these documents in the form of appendices.
Secure Digital Archiving – Software Configuration Management Plan – Page 14
4 CONFIGURATION CONTROL
4.1 Library control
This section describes the central storage facility for all CI’s.
All CI’s are stored in one of three libraries: the development library, the master library
180 or the archive library. Every CI has a subdirectory of the CVS repository that contains
all versions of all files related to the CI.
4.1.1 Development library
The development library contains CI’s that are under construction, and CI’s that are
not official project documents.
185 The following is the directory tree of the development library relative to the root of
the CVS repository.
/DevelopmentLibrary
/Documents
190 /Management
/SCMP
/SPMP
/SQAP
/SVVP
195 /Product
/ADD
/DDD
/SRD
/STD
200 /SUM
/URD
/ATP
/Miscellaneous
/Research
205 /Meetings
/GroupMeetings
/ProgressMeetings
/TeamLeaderMeetings
/ProjectManagerMeetings
210 /Templates
/Presentation
/Prototypes
/Sourcecode
215 Note the Miscellaneous directory contains all non-management/non-product
documents.
Secure Digital Archiving – Software Configuration Management Plan – Page 15
The CM creates the directory and user-group for each CI. Furthermore the CM is
responsible for assigning users to the user-groups so these users have access to the
220 documents they are working on. Every document that is uploaded to the development
library gets a new version tag. Thus no user will ever have to overwrite/delete any
file. The CM is allowed to correct naming and placing of documents if their location
or name doesn’t conform the conventions described herein.
4.1.2 Master library
The master library contains CI’s that have been externally approved. Only the CM can
225 put CI’s in the master library, and once a CI is put into the library it will not be
deleted. De directory tree of the master library is initially empty. But gradually as
more CI’s become approved the directory tree will be comparable to the development
library.
4.1.3 Archive library
The archive library contains CI’s that have been externally released and approved. But
230 CI’s in this library cannot be changed under any circumstances. Only the CM can put
CI’s in the archive library, and again as a CI is put into this library it will not be
deleted. CI’s may only be added to this directory after they have been externally
reviewed and approved, as described in [SQAP, section 5] and [SVVP, section 4.1].
4.2 Media control
All documents are stored centrally on a server provided by the CM. This server is in
235 theory continually reachable under the following domain names:
argos.mine.nu
ftp.argos2002.cjb.net.
cvs.argos2002.cjb.net.
4.2.1 Backup creation
240 There will be an automated daily backup of all libraries at 23:00 CET. The backup
will be stored on a different machine (in a different geographical location) via an
encrypted connection over the internet. The backup itself will consist of single
gzipped tarball.
The following command would create the backup file.
245
tar zcf backup.tar.gz /usr/cvsroot/
Using SCP the backup file is then copied to the other machine running an SSH
daemon. The following command performs this action:
250 scp backup.tar.gz username@hostname:backup.tar.gz
Herein ‘hostname’ is the machine (host) on which the backup.tar.gz file is to be
copied. And furthermore ‘username’ is a valid username on the host.
Secure Digital Archiving – Software Configuration Management Plan – Page 16
4.2.2 Backup restoration
Restoring a backup can be done by extraction of the ‘backup’ file. The result of
255 extraction process will be a single directory containing the CVS repository. However
for CVS to be able to work on this repository all ‘CVS’ subdirectories need to be
removed from the extracted repository. Consecutively this modified repository needs
to be imported in CVS.
260 The following commands restore a backup (assuming active directory /usr/cvsroot):
tar zxf /locationofbackupfile/backup.tar.gz ;
rm –rf $(find | grep “/CVS”) ;
cvs import /usr/cvsroot start
In order to automate the backup process we will create a script that does:
• the creation of the backup.tar.gz file
• the transfer of the backup.tar.gz file via SFTP using non-interactive
authentication
265 Now we use ‘crontab –e’ to add the backup script to the list of cronjobs so the backup
script runs every day at 23:00.
4.3 Change control
This section defines the procedure that needs to be followed for making changes to
any project document.
4.3.1 Development library
For all CI’s with the exception of source code documents, it is only the team leader of
270 the team responsible for a CI that is allowed to checkout (from the repository) a
document belonging to that CI. It is then the responsibility of that team leader to
maintain change control on any checkedout documents.
For source code we make use of the change control system CVS provides.
4.3.2 Master library
275 Once a CI is externally approved the CM can put it in the master library. If author’s
want to make changes to a document inside the master library, then that author has to
take up contact with the QM. The QM will call up a review meeting where all the
changes are approved or rejected. More information regarding the change procedure
can be found in [SVVP, section 4.1]. When changes to a CI are approved the CM will
280 put a copy of the existing version of the CI in the master library to the development
library, and subsequently he will put the new version of the CI in the master library.
As the CM is the only one allowed to remove/create new documents in the master
library, there is no need for change control.
Secure Digital Archiving – Software Configuration Management Plan – Page 17
4.3.3 Archive library
CI’s in this library cannot be modified under any condition. New versions may only
285 be added after they have been externally reviewed and approved as described in
[SVVP, section 4.1]
As the CM is the only one allowed to remove/create new documents in the master
library, there is no need for change control.
Secure Digital Archiving – Software Configuration Management Plan – Page 18
5 STATUS ACCOUNTING
CI’s in such a state that they can be put in either the master library or the archive
290 library have to be reported ‘ready’ by the author of that CI. The CM then copies the
document to the requested library—hereby possibly removing a previous version of
that CI—and record the version tag, and the date of addition in the status-log. This
status log consists of two files with the name ‘status.log’ which are located, one in the
master library and the other in the archive library. Each log contains only information
295 about the CI’s in the library that the log is in.
Furthermore all documents contain a document change record in which all changes
with respect to the previous version are recorded.
Note: Changes in the development library will not be recorded.
Secure Digital Archiving – Software Configuration Management Plan – Page 19
6 TOOLS, TECHNIQUES AND METHODS
All produced documents and tools must be freely available to any group member.
300 Therefore we decided to set up a central storage facility that is able to hold all files so
any group member can access them at any time.
That storage facility has the form of a dedicated machine that runs on OpenBSD 3.0.
From hereon on and without further notice we will refer to this machine as the
project-server. The server has a number of services available to facilitate the
305 document storage and retrieval; they are discussed in the following subsections.
Research documents considering tools and technologies can be found in the Research/
module using CVS.
6.1 FTP
We have used an FTP service since the beginning of the project to store documents on
the project-server. Primarily because it is an easy to setup service and secondary
310 because all project members are familiar with FTP. Though usage of FTP is
functional in storing all documents it lacks change control mechanisms, needed when
more than one person work on the same document. Because of this we want to try
CVS to store our documents. However FTP will be the backup service in case CVS
should fail. Note that the tools that are described above will be kept available on FTP
315 and not by CVS (because of the static nature of these tools).
6.2 Change control with CVS
All documents other then the tools mentioned above are stored on the project-server
using CVS. The place where CVS stores files is called a repository. It is typically a
subdirectory of the file system of the machine that runs the CVS service. Each
subdirectory of the repository contains a CVS subdirectory with CVS-specific files
320 concerning aspects of the files found one layer higher in the directory structure. These
aspects range from user specific rights on these files, to change logs for modifications
made to documents uploaded using CVS.
6.2.1 Modules
Throughout the document you might have encountered modules in relation with the
CVS repository. Modules provide a way to group together files/directories that are
325 related. Each module has a unique name. By specifying this name with the checkout
of a repository, all files that make up the module will be checked out. This is a very
useful tool when using a large directory tree for the repository, as the only thing that a
user has to remember is the module that he is interested in. He thus doesn’t have to
remember the full path to all files that he wants to check out, *tough* it can still be
330 done this way.
6.2.2 Working with CVS
For setting up a CVS service consider reading the manual that can be found on the
CVS homepage: http://www.cvshome.org.
To make use of CVS one must have a CVS-client. The default CVS-client (command
line based) is included in the CVS package that also contains the CVS-server.
Secure Digital Archiving – Software Configuration Management Plan – Page 20
335 Additionally there are CVS clients using a GUI like WinCVS and TortoiseCVS.
Everyone has to decide for himself what client he wants to use. There will be a
manual available for common CVS commands and procedures, it can be found in the
Research/ module using CVS.
6.3 Access control
Furthermore we make use of the Unix file-system permission system, which uses a
340 user/user-group structure to assign permissions to files and directories. All CI’s are in
fact files that are stored on the server, files belonging to each different CI in its own
subdirectory. So this system provides the means to restrict/grant access to CI’s for
individual project members by giving each of them a username. In this analogy users
are added to user-groups and user-groups own the directory of a CI. Every project
345 member is allowed to download and read any document from any directory in the
repository. But only the users in the user-group specified as the owner will be able to
upload files to those directories (and thus make updates to files).
Generally only the leader of a team that is responsible for the creation of a CI will be
in the user-group that owns the directory containing a CI. The leader has to delegate
350 each task to team-members, and provide them with the document.
Secure Digital Archiving – Software Configuration Management Plan – Page 21
7 SUPPLIER CONTROL
Refer to [SQAP, section 11] for the demands that we place on the functioning of tools
supplied by external sources.
Secure Digital Archiving – Software Configuration Management Plan – Page 22
8 RECORDS, COLLECTION AND RETENTION
8.1 Management and product documents
Only the CM is allowed to delete documents from any library
Further rules regarding documents:
355 • All baselines of management and product documents will be kept for the
duration of the project.
• Of the non-baseline management and product documents found in the
development library at least the most recent three versions will be kept in the
library. Older versions can be copied to CD-ROM or directories, or may be
360 completely deleted if their content is considered obsolete by both the author of
the document and the CM.
8.2 Other documents
Miscellaneous documents may be deleted if their contents are superfluous or obsolete,
and only after the CM and the original author of the document have agreed on this.
Secure Digital Archiving – Software Configuration Management Plan – Page 23
APPENDICES
A SR PHASE
365 Additional tools that will be used in this phase:
• Telelogic Tau 4.1, used to create the UML models for the SRD. This tool is
reachable from ‘svstud’ (with a ssh terminal with X relay; or with Exceed)
using the commands:
370 > source /home/tlogic/.m4_login
> ot
• Access template, to dynamically create a traceability tables for the ATP. This
template can be found on the FTP server under the name: RM2000.mdb
B AD PHASE
Additional tools that will be used in this phase:
• Smartdraw, used to create UML models (because ‘Telelogic Tau’) isn’t
reachable for people working at home.
C CODE PHASE
Additional tools that will be used in this phase:
• CommentTracer, used to collect comments embedded in code that are needed
in the [DDD]. This tool can be found on the FTP server.
Usage:
All comment that is prefixed with: ‘///’ or contained in: ‘/**’ and ‘*/’ is
taken out and written to an output file. The tool generated the name this
output-file (it is based on the name of the original input file).
D CVS COMMANDS
First we make the following assumptions for these examples:
- The CVS server we use is called cvs.argos2002.cjb.net
- Every user has a CVS account, we call this account user.
- The CVS root on the CVS server is /usr/cvsroot/
- CVS is installed on the client machine
Before you can start using CVS you will have to login on the CVS server. To do so
we can use the following command:
cvs -d:pserver:user@cvs.argos2002.cjb.net:/usr/cvsroot login
Secure Digital Archiving – Software Configuration Management Plan – Page 24
This will try to create a login to our CVS server as user user. We are now asked for a
password and we enter the password that belongs to our account on the CVS server.
machine:
(Logging in to user@cvs.argos2002.cjb.net)
CVS password:
After entering the correct password in the above screen you will be returned to the
command prompt without any additionally message. If you enter an incorrect
password or username you will be getting an error.
To retrieve a so-called module, which is a set of files and (sub)directories, we use the
following command:
cvs co module
We can add a file to the repository by using:
cvs add filename
We can do this for multiple files and then after we've done all the add commands for
the files we like to add we have to do the actual additions by committing the
additions:
cvs commit
Updating and deleting files goes the same, except instead of add we use either update
or delete.
cvs update filename1
cvs delete filename2
After update or delete commands we also need to commit our changes using:
cvs commit
