0% found this document useful (0 votes)
8 views10 pages

Cvs Version Control

The document outlines the importance of version control in software development, highlighting that about two-thirds of software costs are related to maintenance. It provides a detailed overview of the Concurrent Versions System (CVS), including commands for initializing a repository, importing files, checking out files, committing changes, and managing versions. Additionally, it explains how to handle file differences, releases, and logs within CVS to maintain an organized development process.

Uploaded by

plsdontpageme
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views10 pages

Cvs Version Control

The document outlines the importance of version control in software development, highlighting that about two-thirds of software costs are related to maintenance. It provides a detailed overview of the Concurrent Versions System (CVS), including commands for initializing a repository, importing files, checking out files, committing changes, and managing versions. Additionally, it explains how to handle file differences, releases, and logs within CVS to maintain an organized development process.

Uploaded by

plsdontpageme
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

Content from The College

Version Control

• about 2/3 of the cost of a software product is spent on maintenance


• maintenance involves revising source code and generating new
executables
• sometimes changes need to be undone and an earlier version recalled
• there may be several versions of softare in production while new ones
are being developed
• such complex systems need version control to help avoid problems

cvs (Concurrent Versions System)

• cvs controls who is allowed to update files


• for each update, the programmer and reason for change are recorded
• the most recent version of each file is stored with sufficient information
to recreate all previous versions
• versions of several files may be grouped together into releases
• storing changes to files saves considerable disk space over saving
complete versions of files
• purpose of each cvs command can be displayed using cvs * -H
• to get help on an individual command, use cvs -H command
• the examples use the same sample programs as used in the creation of
libraries: prog2.h f1.c f2.c prog2.c
• cvs commands:
o init - create a source repository, for example:

cvs -d ~/cvsroot init


▪ instead of using "-d" option, could set environment
variable: export CVSROOT=~/cvsroot
▪ remaining commands assume that "CVSROOT" has been
set and exported
▪ "cvsroot" is often used but can be anything; it would not
normally be in a user's home directory in a multi-
programmer project
▪ specified directory must be an absolute path name
o import - import source files into repository, for example:
cvs import -m "Import source files"
prog2dir vendor-tag start
▪"-m" option specifies message to write to history files
▪ "prog2dir" is the directory within the repository to place the
source files, also called a "module"
▪ "vendor-tage" is a vendor tag, useful when working with
software developed elsewhere
▪ "start" must be specified
▪ all the files in the current directory will be copied
appropriately, then the original source files should be
deleted to avoid confusion
o example of creating a repository and importing source files:
o ==> ls
o f1.c f2.c prog2.c prog2.h
o ==> export CVSROOT=~/cvsroot
o ==> cvs init
o ==> cvs import -m "Import source
files" prog2dir vendor-tag start
o N prog2dir/prog2.c
o N prog2dir/prog2.h
o N prog2dir/f1.c
o N prog2dir/f2.c
o

o No conflicts created by this import


o

o ==> rm *
o ==> ls
o ==> _

o checkout - checkout source files into our "sandbox", for example:

cvs checkout prog2dir


▪ all the files in the module "prog2dir" will be checked out, into
a subdirectory called "prog2dir"
▪ can checkout individual files, for example: cvs
checkout prog2dir/prog2.c
o example of checking out a module:
o ==> mkdir ~/sandbox
o ==> cd ~/sandbox
o ==> cvs checkout prog2dir
o cvs checkout: Updating prog2dir
o U prog2dir/f1.c
o U prog2dir/f2.c
o U prog2dir/prog2.c
o U prog2dir/prog2.h
o ==> ls
o prog2dir
o ==> cd prog2dir
o ==> ls
o CVS f1.c f2.c prog2.c prog2.h
o ==> _

o commit - commit changes made to source files in sandbox, for


example:

cvs commit -m "Added a comment"


prog2.c
▪"-m" option specifies message to write to history files
▪ if not in "prog2dir" directory, path to "prog2.c" must be
included
▪ this will fail if "prog2.c" has been changed by another user
since it was checked out
o example of changing a file (added a comment to "prog2.c") and
committing:
o ==> cvs commit -m "Added a comment"
prog2.c
o

/home/lczegel/cvsroot/prog2dir/prog2
.c,v <-- prog2.c
o new revision: 1.2; previous
revision: 1.1
o ==> _

o update - merge changes with source that was changed since it


was checked out, for example:

cvs update prog2.c


▪ this will create a new file with both sets of changes, you
must decide how to merge them, then commit
o add - add new files to repository, for example:

cvs add makefile makefile2


▪this will mark "makefile" and "makefile2" for inclusion in
repository, then they must be commited
▪ if an entire directory is added, it doesn not need to be
committed
o example of adding new files and committing:
o ==> cp ~lczegel/UNIX/makefile
~lczegel/UNIX/makefile2 .
o ==> cvs add makefile makefile2
o cvs add: scheduling file `makefile'
for addition
o cvs add: scheduling file
`makefile2' for addition
o cvs add: use `cvs commit' to add
these files permanently
o ==> cvs commit -m "Added makefiles"
makefile makefile2
o

/home/lczegel/cvsroot/prog2dir/makef
ile,v <-- makefile
o initial revision: 1.1
o

/home/lczegel/cvsroot/prog2dir/makef
ile2,v <-- makefile2
o initial revision: 1.1
o ==> _

o rtag - freeze a release, for example:

cvs rtag Release_1 prog2dir


▪this will allow extracting the current source files, regardless
of any additional development
▪ "-F" option will move tag if it already exists
▪ "-d" option will delete the tag
o example of freezing a release:
o ==> cvs rtag Release_1 prog2dir
o cvs rtag: Tagging prog2dir
o ==> _

o remove - remove files from repository, for example:

cvs remove makefile


▪this will mark "makefile" for removal from repository, then it
must be commited
▪ the files must be removed from the sandbox before they can
be removed from the repository
o example of removing a file from the repository:
o ==> rm makefile
o ==> cvs remove makefile
o cvs remove: scheduling `makefile'
for removal
o cvs remove: use `cvs commit' to
remove this file permanently
o ==> cvs commit -m "Removing
makefile" makefile
o

/home/lczegel/cvsroot/prog2dir/makef
ile,v <-- makefile
o new revision: delete; previous
revision: 1.1
o ==> _

o diff - display differences, for example:

cvs diff -c prog2.c


▪ this will display differences between source file in sandbox
and in repository
o example of changing a file (added another comment to "prog2.c")
then displaying the differences::
o ==> cvs diff -c prog2.c
o Index: prog2.c
o

====================================
===============================
o RCS file:
/home/lczegel/cvsroot/prog2dir/prog2
.c,v
o retrieving revision 1.2
o diff -c -r1.2 prog2.c
o *** prog2.c 9 Mar 2007 23:59:12
-0000 1.2
o --- prog2.c 10 Mar 2007
00:14:45 -0000
o ***************
o *** 1,6 ****
o --- 1,7 ----
o #include <stdlib.h>
o #include "prog2.h"
o /* this is the first comment
added */
o + /* this is another comment to
display differences */
o int main(void) {
o int num2;
o num2 = f1();
o ==> _

o export - extract a release, for example:

cvs export -r Release_1 prog2dir


▪ this will extract the source files that were frozen with the
given tag
o example of exporting a release, note that the deleted file
"makefile" is in Release_1, since it was removed after Release_1
was tagged::
o ==> mkdir ~/release1
o ==> cd ~/release1
o ==> cvs export -r Release_1
prog2dir
o cvs export: Updating prog2dir
o U prog2dir/f1.c
o U prog2dir/f2.c
o U prog2dir/makefile
o U prog2dir/makefile2
o U prog2dir/prog2.c
o U prog2dir/prog2.h
o ==> ls
o prog2dir
o ==> ls prog2dir
o f1.c f2.c makefile makefile2
prog2.c prog2.h
o ==> _

o log - display log entries, for example:

cvs log prog2.c


▪this will display all log entries for "prog2.c" in repository
o example of displaying log entries::
o ==> cd ~/sandbox/prog2dir
o ==> cvs log prog2.c
o

o RCS file:
/home/lczegel/cvsroot/prog2dir/prog2
.c,v
o Working file: prog2.c
o head: 1.2
o branch:
o locks: strict
o access list:
o symbolic names:
o Release_1: 1.2
o start: 1.1.1.1
o vendor-tag: 1.1.1
o keyword substitution: kv
o total revisions: 3; selected
revisions: 3
o description:
o ----------------------------
o revision 1.2
o date: 2007-03-09 18:59:12 -0500;
author: lczegel; state: Exp;
lines: +1 -1; commitid:
497b45f1f4d04567;
o Added a comment
o ----------------------------
o revision 1.1
o date: 2007-03-09 18:42:33 -0500;
author: lczegel; state: Exp;
commitid: 48d345f1f0e94567;
o branches: 1.1.1;
o Initial revision
o ----------------------------
o revision 1.1.1.1
o date: 2007-03-09 18:42:33 -0500;
author: lczegel; state: Exp;
lines: +0 -0; commitid:
48d345f1f0e94567;
o Import source files
o

====================================
====================================
=====
o ==> _

o release - release a module after installing changes, for example:

cvs release prog2dir


▪this will check for any changed files that have not been
committed
▪ it will also remove all files in the sandbox if "-d" option is
used
o example of releasing a module:
o ==> cd ..
o ==> ls
o prog2dir
o ==> cvs release -d prog2dir
o M prog2.c
o You have [1] altered files in this
repository.
o Are you sure you want to release
(and delete) directory `prog2dir': y
o ==> ls
o ==> _

You might also like