CS390 UNIX Programming
Concurrent Version System
Nov. 11, 2010
Slide #1 11/3/2011
Concurrent Version System
Record keeping
Compare the current state of a program with how it was at a
point in the past
Restoring: Get a historic copy of the program based on
A particular date
A snapshot with release tag
• Normally, snapshots should be created for each release during
the course of development
• In case a bug is reported in a particular release, you can just
check out the source code for that release.
Help with multi-people working on the same project
Two mostly used open source systems: CVS & SVN
Open source, it’s FREE under GNU GPL
Support Windows and Unix/Linux platforms
• For Windows System: TortoiseCVS, TortoiseSVN
Slide #2 11/3/2011
Basic Terms in A Concurrent
Version System
Repository:
where the projects are stored, normally on a reliable system
with normal backup
Revision:
one “snapshot” of a constantly changing program
Check out:
to get a working copy of the project/module from the
repository
Working copy:
the copy you are working on which was checked out from the
repository
Commit /check-in:
send the changes from your working copy to the repository
Slide #3 11/3/2011
Basic Terms (Cont’d)
Log message
A comment you attach to a revision when you commit it during
the check-in.
A changeLog.txt commonly sits in the top directory which
includes all the log messages (you need to update this file with
your log message and commit in your change as well)
Update
to merge other’s changes from the repository to your working
copy
An update is mandatory before you can checkin/commit the
changes you have made
Conflict
In case other developers have modified and committed the
changes on the same section of the same code you have been
working on, no files checked-in yet. You have to resolve this
manually before you can commit your change
Slide #4 11/3/2011
CVS/SVN: a Copy-Modify-Merge Model
Each developer will have his/her own copy of the source
codes
Each developer will check out the source from the repository
(workspace)
Each one works in his/her own working copy.
Normally (Ideally), developers work on different parts of
one project
Check in/ commit your changes
You need UPDATE the source code first in case the code has been
modified by other developers.
The update will merge other’s changes with yours to the codes you
work on.
If you have changed the same section of the code as what other
does, conflict occurs . This has to be resolved first by you
before you can check in your changes.
Thorough testing the merged copy before committing
Slide #5 11/3/2011
(1)
Harry and Sally (2) Both
checkout src working on
a file
(3)
Sally
commit
(4)
Harry
tried to
commit but
failed
Slide #6 11/3/2011
(5) (6)
Harry
Update
(7)
(8)
Harry
Sally
Check-in
Update
Slide #7 11/3/2011
Conflict
Conflict occurs when Harry and Sally are working on
the same segment of the same file
When Harry updated his file, trying to merge his changes
with the codes updated in repository by Sally, his file will
be flagged as in conflict state
Harry has to resolve this manually. The software (such as
the Subversion and CVS) has no way to know which change
should be kept.
Generally, two people working on the same segment
of the same code is very infrequent
Slide #8 11/3/2011
CVS Repository
Repository Creation
cvs –d /full/path/to/your/cvs/Repository init
Normally created by super user, but you can create one in your
home directory to track the changes of your programs
Types of CVS Repository
Secure CVS implementation using “:ext:” with ssh
Unsecured: “:pserver:” method, normally for public access
• read only, you can not commit your changes to the repository
Access CVS Repository
Two environmental variables need to be defined either in the
current session of the shell or in the shell initialization file such as
.bashrc or .login
• CVS_RSH=ssh
• CVSROOT=:ext:hlin@linux.cs.uah.edu:/home/csuser/hlin/local/Repository
• export RSH CVSROOT
CVS does not really keep version control for directories
Slide #9 11/3/2011
Working with CVS
Create a new project (module) in CVS repository
cd to the top directory of the source tree ( the project you want to save
in the repository)
cvs import –m “message” module_name vend_tag rel_tag
The module name can be the same as that of your source tree, but not
necessary.
Vender tag and release tag are mandatory, used for some other rare
cases, most of time, you can put any two terms there
Check out a working copy of the module
cvs co module_name
You can give a different name if you like, but not suggested
cvs co –d new390 module_name
• Useful when you need to work with different versions of the module at the
same time
“-q” option: quiet with some info displayed on the screen
“-Q” option: more quiet, even less info displayed
Remember to set the CVS_RSH & CVSROOT
Slide #10 11/3/2011
Working with CVS (Cont’d)
Working/modifying programs inside the checkout working directory
Update your working copy
cvs update
cvs update –d (in case a new directory has been created since
you have checked out)
Always working on the latest version, do update often
Commit your changes to the central repository:
CVS command: cvs commit or cvs ci
cvs –m “log message” commit file1 file2 file3
• In case no file name provided, CVS will compare every file with what in
the repository and commit those being modified
• In case no “-m” option, CVS will provide a window, ask you to enter the
log messages to state what have been modified on these files
CVS will also check and compare the version of your copy with that
in the central repository, if they have been updated (checked in by
others since your checked out or updated last time), it will ask you
to do an update first before committing
Slide #11 11/3/2011
CVS Revisions
Revision number in CVS
Each file in a project has its own revision number
Every time the file is checked in, the revision is updated for that file
• The last digit of the reversion number is incremented by 1
Different files will be modified different times, thus, will have different
revision numbers.
cvs status file_name
To see the revision number of a file
cvs log file_name
To check the track of changes of a file and to find out who has done what
cvs diff filename
To see what you have changed to the latest version of a file in the
repository before you update it
cvs diff –r old_version filename
Compare with an earlier/older version
All the options of diff utility can be applied here after diff
cvs diff –u –r 1.3 –r 1.4 filename.cpp
Compare two older revisions of the file
Slide #12 11/3/2011
Resolving Conflicts
If another developer has modified the same section of the
same code and has committed the change, conflict occurs
CVS will delimit the conflict with the conflict markers in the
merged file after the update
>>>>>> (latest revision number in the repository)
This has to be solved manually before the source code can be
committed (checked-in)
Slide #13 11/3/2011
Other CVS Commands
Adding files: a two-step process
1. cvs add newfile.cpp
2. cvs commit newfile.cpp
Adding directories: one step process, no need to commit
cvs add newdirectory
Removing files from repository: a three-step process
rm filename.cpp
cvs remove filename.cpp
cvs commit filename.cpp
Removing directories
You need to remove the files of that directory first
cvs update –P
• CVS will prune any empty directories from the working copy
• The empty directory is actually still in the repository
• (you can physically log on to the server and get into the repository to
delete the directory there, but it’s useful to keep a record there
Renaming files and directories
equivalent to add / remove files and directories
Slide #14 11/3/2011
Snapshot: Date
Used to retrieve a previous revision of the files of a
project based on date
$ cvs –q update –D “1999-04-19” from top of your working
directory
• Retrieve the highest revision number on that date/time and revert
the files in the working copy to the prior revisions if necessary
• It updates with the revision at the beginning of that date, starting
at middle night, so specify the time is necessary
• $ cvs –q update –D “1999-04-19 23:59:59 GMT”
The repository stores dates in Universal Time
$ cvs co –D “1999-04-19” project_name as a fresh start
Acceptable date formats
cvs update –D “19 Apr 2001”
cvs update –D “19 Apr 2001 20:05”
cvs update –D “19/04/2001”
cvs update –D “3 days ago”
cvs update –D “5 years ago”
Slide #15 11/3/2011
Snapshots: Tagging with Tag
tagging”: Making a moment in time, a better way
Difficult to memorize the date of the event
Gives a label to the collection of up-to-date revisions of the project
Snapshot
A set of files and associated revision numbers from the project, the
revision numbers are not necessary the same among the files.
A defined tag will be sticky to those revisions even later the files
will be updated with new revisions.
Tagging the module with the latest revisions in the repository
cvs –q tag Release_March_29_07
Tag name
• start with a letter, then letters, digits, hyphens and underscores, no
space, no periods, colons, commas, etc. such as Release_March_29_07
Setting tag in the top of the working directory
Tagging regularly, and often
for milestones, such as public releases, a stable stage during the
development
the addition or removal of some major features.
Slide #16 11/3/2011
Retrieve a Snapshot
Retrieving a snapshot with the tag_name, the
tag_name is treated the same as the revision
number
Fresh check out
cvs co –r tag_name module_name
Switch your current working copy to the snapshot
cvs update –r tag_name
The list of tags can be found with
cvs log filename
Slide #17 11/3/2011
Branches
CVS branch splits a project’s development into
separate, parallel branches.
The trunk: the major development
A branch is just like another working copy of the project with
its own revision numbering system.
Changes made on one branch do not affect the other
Keep track bugs and bug fixes for a particular release
CVS can’t record the fixes if checking out the previous release
with that snapshot and fix from there
• you can’t check in the changes
You cannot fix the bug in the current working copy, they are
not the same as the previous release, many changes have been
done since then!
Slide #18 11/3/2011
Branching
Check out the previous release version based on the
tag_name, the snapshot
cvs –q co –d project_old_release –r R_06_11_10 proj_name
The “ –d project_old_release” gives a different directory name
from the trunk what you are currently working on.
Create a branch by retagging it with –b option
In top dir of the project, ( cd project_old_release)
cvs –q tag –b R_2006_11_10_bugfixes_branch
The tag name, “R_2006_11_10_bugfixes” will be used as a
label by which the branch can be retrieved later.
Branch tags are looked the same as non-branch tags
(such as for the snapshot with tagging)
Conventionally, the tag for branch will be suffixed with word
“branch”, such as: Release-2006_11_10_bugfixes_branch to
distinguish it from other tags
Slide #19 11/3/2011
More about CVS Branch
Checking out the branch
From your current working directory
cvs update –r Release-2000_11_10-bugfixes
Check out without a working copy (recommended)
cvs co –d proj_branch –r R_2006_11_10-bugfixes myproj
Merging (join) branch to trunk: the bug fixes for the old release
need to be carried into the trunk
In your current working directory (the trunk)
cvs –q update –j R_2006_11_10_bugfixes
• This will merge what in the branch to the source in the trunk
• Conflict possible, resolve manually if necessary
You might want to check if there are any differences between the trunk
and branches with cvs diff –u –r Release-2006_11_10-bugfixes
Check in the changes to the trunk
cvs –q ci –m “merged from branch Release-2006_11_10-bugfixes”
Slide #20 11/3/2011
Multiple Merges
In case that 2nd bug is found in that old release, you checked out the
branch and fixed bug. Then you want to merge this fix into the trunk
with (do the following on top of the trunk)
cvs –q update –r R_2006_11_10_bugfixes
You will get conflict: it tries to merge the first bug fix to the current
working copy in the trunk which has already been updated earlier.
With two “-j” options
One way: specified the starting point on the branch for merging with
“date”
cvs –q update –j “R_06_11_10_bugfixes: 2 days ago” -j “R_06_11_10_bugfixes”
• The first “-j” gives the starting point on the branch
• When the branch tag name followed by a colon, then a date (any of those
previous mentioned format), CVS will include only changes later than that date
Another way: tagging every bug fix, then using the tag name
cvs –q update –j Release_bugfixes_1 –j Release-2006_11_10-bugfixes
TAG THE SOURCE AS OFTEN AS YOU CAN
Slide #21 11/3/2011
CVS Clients on Windows
TortoiseCVS: http://www.tortoisecvs.org/
Free available under GPL
Check out modules, update, commit and see the
differences by clicking on files and folders within Explorer
Under the desired folder opened with Explorer
Right click on mouse and select “CVS check out”
Follow the direction from therein to setup the server and
module name, revision, etc
CvsGui: http://www.wincvs.org/
Documentation at http://cvsgui.sourceforge.net/doc.html
Slide #22 11/3/2011
Subversion, a Replacement for CVS
CVS has not been maintained or updated for years
Subversion has most of the features of CVS, with additional
good features
Simple version schemes, easy file renaming and tracking
Directories are versioned and tracked
Read http://subversion.tigris.org/ for the features of subversion
Commands
svn (intead of cvs)
svn commit –m “my file” myfile.c
svn log myfile.c
svn status myfile.c
svn up or svm update
svn diff –r 2:3
svn mv myfile.c myfile_new.c
On line book: http://svnbook.red-bean.com/
Slide #23 11/3/2011