Computer Science 223 Laboratory Exercise: CVS Concurrent Versions System

The CVS Concurrent Versions System

Summary: This lab provides practice with CVS (a Concurrent Versions System) within the context of the class project.

Background

As the class progresses from the specification and design stages of the Scheduler project to coding, coordination of group efforts becomes particularly important. Specifically, we must work within a system that allows the following:

Each group must be able to code, modify, compile, and test its class(es) independently of other groups. That is, when code is under development by a group, that code should not prevent other groups from coding and testing their work.
When a group has reached a stable point within its code development, the code should be made available to the rest of the students in the course.
As a group is testing, the testing should take place using the latest stable classes from other groups.

The CVS Concurrent Versions System

CVS is a version control system designed specifically to address the needs of groups developing software, documentation, and other materials. While some details of CVS may be specific to this version control system, many of the basic ideas apply quite generally. Thus, as students move from this project in this course to other projects either at Grinnell or elsewhere, students are likely to find similar ideas employed in whatever software development system they encounter. Details may differ, but many control systems will have a similar purpose, and developers will finding programming in such environments share common elements.

Resources

Information of CVS (a Concurrent Version System) may be found on-line in three ways:

The on-line version of Open source development with CVS may be found at http://cvsbook.red-bean.com/cvsbook.html. While this version does not include various recent updates, it does provide a solid reference. Chapter 1, An Overview of CVS provides a reasonable introduction to this system.
On a MathLAN workstation, local help may be found by typing info cvs in a terminal window. Basic movement through this documentation proceeds as follows:
- use the up and down arrow keys to identify a desired topic, and then hit <return> for information on that topic.
- type the letter n to go to the next topic
- type the letter p to go to the previous topic
- type <Ctrl>c to exit the documentation
The manual, Version Management with CVS, by Per Cederqvist et al is available in the lab. This manual should not circulate and is likely to be found in a binder on the shelves in Science 2417.

Steps for this Lab:

Read the Overview of CVS in either on-line system, using http://cvsbook.red-bean.com/cvsbook.html in a browser or the info cvs in a terminal window.

Using CVS on MathLAN

Work with CVS requires some initialization and preparation. Thereafter, work follows a relatively simple pattern.

Setup for CVS: On MathLAN, CVS runs on server cvs.cs.grinnell.edu. While one could include directions to this server with each CVS interaction, work is simplified by placing the a few lines in your file .bash_profile, found in your home directory. The following code is designed for the instructor (username walker).


# Use the CVS repository at cvs.cs.grinnell.edu.

CVSROOT=:pserver:walker@cvs.cs.grinnell.edu:/cvs
export CVSROOT

Insert the above lines into your .bash_profile file, changing walker to your own username.
After updating .bash_profile, you will either need to log out and back in again or you can run the command
```
source ~/.bash_profile
```
from the terminal window you will use in the following steps.

Access to the CVS is password protected. However, once you log in a first time, your account places password information in file .cvspass in your home directory. Since this information is stored in clear text, you should not use your regular password. (For this course, Mr. Stone will assign random passwords to each student. After a first use, you are unlikely to need to remember this detail further.)

Log in to the CVS system by typing the following command in a terminal window:
```
cvs login
```
You will be prompted for your password.

Normal Use of CVS

In working with CVS you will want to base your activity at a logical subdirectory. The following commentary assumes you have moved to that subdirectory in a terminal window.

After initial set up, normal use of CVS on MathLAN follows these several steps:

Step Name	Command	Commentary
Get source files	`cvs checkout scheduler`	Obtain new copies of files for the `scheduler` project
Edit `yourFile.java`	`cd scheduler xemacs yourFile.java`	Change directory to the scheduler project Start editing your file
Compile/Run Tests	`jcompile, jrun`
Commit changes	`cvs commit -m "log message about update" yourFile.java`	Put the new version of `yourFile.java` back in the repository
Clean up	`cd .. cvs release -d scheduler y`	Move up one directory check modifications are committed before removing files verify you want to remove committed files/directories

Use of CVS for this Course

For this course, each group will be responsible for working on its own class. While CVS allows any user to revise any file, such flexibility could undermine development of software if one group were to change the files of another group. Further, changes must be controlled, so that software found in the CVS repository represents stable, working code. This leads the following rules for this course:

Groups are expected to change their own class file only; a group may not change files of other groups!
Groups should commit changes to their files ONLY after compiling and testing those changed files with the stable files from other groups.

Using these rules as a base, you should try checking out classes, changing the class of your group, committing the change, and cleaning up.

Check out a copy of all classes for the scheduler project.
Prepare to edit your group's class, bringing up the file in an editor.
Reviewing all use cases for this project, make a list of the methods required for your class. Add these methods to your class, showing parameters, return types, pre-conditions, post-conditions, and what use case(s) the method is designed to handle. (Beyond these method headers, however, you should leave method bodies as stubs only.)
Compile your revised class, correcting any syntactical errors.
Commit your revised class to the repository. (Be sure to commit only your class -- not all classes that you have checked out.)
Clean up your files and directory.
Check out a new version of all classes, and verify that your changes are present.
Add any data attributes to your class that you think you will need when implementing the required methods.
Again, commit the changes and clean up.

This document is available on the World Wide Web as

http://www.cs.grinnell.edu/~walker/courses/223.sp02/lab-cvs.html

created March 31, 2002 last revised April 1, 2002


For more information, please contact Henry M. Walker at walker@cs.grinnell.edu.