CSE306 Operating Systems
Projects
CVS/SSH tutorial
1
What is CVS?
• Concurrent Versions System
• Version Control System
• Multi-developer environment
2
CVS
Developer
1
Developer
2
Repository
Developer
4
Developer
3
3
Ideal development with CVS
development
checkout
checkin
update
Developer A
repository
Developer B
4
Definitions-Repository
• The Repository is a directory tree containing
the CVS administrative files and all the RCS
files that constitute "imported" or "committed"
work.
• Kept in a shared area, separate from the
working areas of all developers.
5
Definitions-RCS
• An RCS file is a text file containing the
source text and the revision history for all
committed revisions of a source file.
• Stored separately from the working files,
in a directory hierarchy, called the
Repository.
• RCS is the "Revision Control System"
that CVS uses to manage individual files.
RCS file names normally end in ",v".
6
Definitions-Working file
• A working file is a disk file containing a
checked-out copy of a source file that earlier
had been placed under CVS. If the working file
has been edited, the changes since the last
committed revision are invisible to other users
of CVS.
• A working directory is the place where you
work and the place from which you "commit"
files.
7
Definitions-Checkout
• “Checking out" is the act of using the
"checkout" command to copy a particular
revision from a set of RCS files into your
working area.
• You normally execute "checkout" only once per
working directory (or tree of working
directories), maintaining them thereafter with
the "update" command.
8
Definitions-Revision
• A "revision" is a version of a file that was
"committed" ("checked in", in RCS terms)
some time in the past.
• Each version of a file has a unique revision
number.
• Every file in a CVS repository can contain
many versions, which are given revision
numbers in form x.y[.x.y[...]].
• ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
9
Definition-Tag-symbolic revision
• A release of a system will have many
different revision numbers
• To let you find all the files in a release, use
tags.
• Read Manual if you are interested
10
Definition-Branch
• Version number can contain more than two
numbers to mark branches.
Reasons to branch:
• fix bugs in product while working on next
version
• work on subproject that will take a week to
finish
11
Working on branches
patch
cvs tag -b rel_1_fix
1.2.2.1
1.1
1.2
1.2.2.2
1.3
release_1
1.4
release_2
cvs up -r rel_1_fix
cvs tag release_1
cvs tag release_2
12
Real development with CVS
checkin
conflict
checkin
update
resolution
Developer A
repository
Developer B
X
conflict
13
CVS and the Development Cycle
1. Check out source files in working
directory.
2. Edit source files.
3. Unit test your code.
4. Update working files to merge in
changes from other developers (if
necessary).
14
CVS and the Development Cycle
5. Test again if the sources were merged
on step 4.
6. Commit changes.
7. Repeat from step 2 until you have a
new release.
8. Tag the release.
9. Submit the module name and release
tag for integration build.
15
Useful CVS commands
cvs [cvs-options] command [cmdoptions] [files]
cvs checkout
Check out source for editing.
cvs commit check files into the repository (check in
cvs add
Add new file/directory to repository.
cvs remove Remove an entry from the repository.
cvs update Bring working files into sync with
repository.
16
Useful CVS Commands(con.)
cvs diff
Compare working files to version in
repository or versions inside the repository.
cvs log
Show revision history for files.
cvs status Show status of checked out files.
cvs tag
Label the sources.
17
Notes
• When to commit:
Commit to mark a working state that you
might want to return to later.
For more information on CVS, please see
• www.cvshome.org
18
Starting the Project
with CVS/SSH
19
Enable us to check your project
• To enable us to check the log, you must do
this:
cd ~
chmod 711 .
mkdir ~/.ssh
chmod 700 ~/.ssh
cat ~kifer/id_cse306.pub >> ~/.ssh/authorized_keys2
20
Start working with CVS
• Create empty repository
cvs -d ~/CVSROOT init
• protect yourself from copycats!
chmod -R 770 ~/CVSROOT
21
Working with partner
• if you are working with a partner and are
assigned to the same user group, say c30600 then also type the following two
commands:
chgrp -R c306-00 ~/CVSROOT
make sure new directories are created with
the right permissions:
chmod -R g+s ~/CVSROOT
22
Create directory structure for your
repository
• your OSP project dir
mkdir ~/your-project-dir/OSP
• your project dir for Proj 1
mkdir ~/your-project-dir/OSP/memory
• your project dir for Proj 2
mkdir ~/your-project-dir/OSP/threads
• your project dir for Proj 3
mkdir ~/your-project-dir/OSP/devices
23
Import directory structure
• cd ~/your-project-dir/OSP
• Import directory structure of your OSP project
into your CVS repository
cvs -d ~/CVSROOT import -m "Created OSP
directory structure" OSP osp start
• In the above, `osp' and `start' are called "vendor"
and "release" tags and can be anything. CVS
requires them for import, but you can forget about
them from now on.
24
Remove it
• Set the appropriate permissions for the OSP
module in the cvs repository. Read/write for you
and partner -- nobody else
chmod 770 ~/CVSROOT/OSP
• Remove the OSP dir structure you just created
(not the CVSROOT repository)
cd ~/your-project-dir
• BE CAREFUL HERE!!!!!!
rm -r OSP
25
Check Out
• Checkout OSP from the repository (this lets
OSP create the necessary structures)
cvs -d ~/CVSROOT checkout OSP
• Protect yourself!
chmod 700 OSP
26
Partner
• Your partner should also check out the same
thing, but, of course, use ~your_account_id
instead of just ~. Let's suppose you are
'john': Your partner does:
cd ~/your-partner's-project-dir
cvs -d ~john/CVSROOT checkout OSP
chmod 700 OSP
27
The following is a bit outdated, but OK if you
are not planning to use Eclipse
28
Add new files
• Adding files (such as memory.c) to your
repository using the command 'cvs add‘
• Use `cvs add filename' to tell CVS that you want
to version control the file.
• Command: cvs add [-k kflag] [-m message] files
The `-m' option specifies a description for the
file. This description appears in the history log
29
Commit
• Use `cvs commit filename' to actually check
in the file into the repository. Other
developers cannot see the file until you
perform this step.
30
Where should I work?
• Your repository should be on
ug.cs.sunysb.edu
• Remote access to UG lab by SSH (no GUI)
• Working at home with Linux/FreeBSD
using Emacs/Xemacs or Eclipse
• Working at home with MS Windows
using TortoiseCVS or Eclipse
31
UG Server
• Request a UG account at
www.ug.cs.sunysb.edu
• Read www.ug.cs.sunysb.edu to begin
working
• Remote access to UG server by SSH only!
32
Working at home with Linux/FreeBSD
• Set the environment variable CVS_RSH to ssh
• You can checkout a copy directly to your home computer as
follows (assuming that you are 'mary' in the UG lab):
cvs –d :ext:mary@ug.cs.sunysb.edu:your_homedir/CVSROOT checkout OSP
(this is all in 1 line!!)
• Note: your_homedir must be the full path name to your home
directory at ug.cs.sunysb.edu
• Then you can access the rest of the commands using the
Emacs/Xemacs graphical interfaces.
• You can also access the repository using Eclipse:
– http://wiki.eclipse.org/CVS_Howto
• There are other graphical interfaces for Linux as well
33
Emacs and Xemacs Interfaces
• XEmacs
– Nice interface to CVS, called pcl-cvs. Most of the CVS
commands are available through the Tools/PCL_CVS
menu of XEmacs.
– After you invoke M-x cvs-update, you get a CVS
buffer, where you can invoke even more commands
through the top-level menu called CVS
• Emacs has a similar interface, called pcvs
34
TortoiseCVS and Eclipse
• Download a copy from
www.tortoisecvs.org
• TortoiseCVS+SSH:
– http://www.tortoisevs.org/faq.shtml#ssh
• Eclipse with CVS and SSH:
– http://wiki.eclipse.org/CVS_Howto
35