CSC 325	Grinnell College	Fall, 2008

Databases and Web Application Design

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 project development progresses, coordination of group efforts becomes particularly important. Specifically, we must work within a system that allows the following:

Each person within a group must be able to code, modify, and test her/his script(s) independently of other students. That is, when code is under development by a student, that code should not prevent other group members from coding and testing their work.
When an individual has reached a stable point within her/his code development, the code should be made available to the rest of the students in the group.
As a student is testing, the testing should take place using the latest stable scripts from other students in the group.

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 these 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

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.

Initialization for 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

Steps for this Lab:

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.

With this work done correctly, you will NOT need to use the cvs login command in future interactions.

Getting Started with your CSC 325 Prroject within the CVS System

To use CVS for a project, one project-group member must place the new project into CVS. In the jargon of CVS, the new project is imported into the CVS system.

The following approach is strongly recommended for each CSC 325 project.

Steps for this Lab

Work with your group to organize your project into files:
1. One common style sheet will give a uniform look and feel for the site.
2. One common file will contain any desired system-wide variables.
3. One common file will contain libraries of common functions.
4. A common file should be developed for standard initial tasks, such as
  1. logging into the mysql (this script should include the line that picks the specific database)
  2. a common header for each page on the site
  3. checking passwords/authentication (as needed)
5. Each Web page will have its own html/php file, with the first part of each page including any library functions, database connections, security, stylesheet information, and header(s).
For each group project, database tables will be stored within the csc325 database. Tables for a group should begin with the project name or abbreviation, so tables for one group do not have the same name as those for another (e.g., ExitSurvey1Questions).

Each group is strongly encouraged to create a file that clarifies the structure of its database tables. For example, various labs in this course have contained create and insert statements for the initial setup of a lab. Such statements should be documented in a project file.

Place initial (possibly null) versions of each of these files in a a project directory. This project directory should NOT contain any other files.

Now use these new files as the basis for your project files with CVS.

Within a terminal window, change directory to the newly-created directory from step 6.
Create the new project within CVS with the command:
```
   cvs import -m "project initialization" projname  username start
```
To clarify this line:
- The string after the required -m option provides an annotation for this entry into CVS.
- projname is an identifier that will provide the reference name for your future interactions with this project.
- username is a group name or a group member's username.
- start is a descriptor for this package; using the word "start" itself is suggested

At this point, your system should be entered into CVS. Note, however, that the material in the current directory is not considered to be a CVS working copy of your system. A working copy of the system requires that you check out a current version from CVS. That is the next part of this lab.

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 projname`	Obtain new copies of files for the `projname` project
Edit `yourFile.java`	`cd projname xemacs yourFile.java`	Change directory to the projname 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 projname 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 project. The group will need to determine who will be working with which script(s) when; that is, project management is left to each group. Please talk with the instructor early and often to clarify these assignments.

While CVS allows any user to revise any file, such flexibility could undermine development of software if one group member were to change the files of another. 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 project files only; a group may not change files of other group's project!
Each group should consult extensively on the common-library files (e.g., system variables, common functions, style sheet, header). Only when all have agreed should one of these files be updated.
Each group must clarify which person will be developing the code for which scripts. Then, each individual should modify only those files assigned by the group. An individual can check out a full collection of scriptss for the project, but the individual should edit only those assigned by the group.
Individuals should commit changes to their files ONLY after testing those changed files; so only working files are kept in the CVS repository.
Initially, scripts may have minimal functionality (although links to other scripts may be in place). The challenge for the semester is to add functionality systematically in subsequent prototype versions.

Using these rules as a base, you should try checking out scripts, changing your script(s), committing the change, and cleaning up.

Check out a copy of all scripts for your projname project.
Edit your script as needed.
Test your revised script, correcting any errors.
Commit your revised script to the repository. (Be sure to commit only your script -- not all script that you have checked out.)
Clean up your files and directory.
Check out a new version of all scripts, and verify that your changes are present.

This document is available on the World Wide Web as

http://www.walker.cs.grinnell.edu/courses/325.fa08/cvs.shtml

created 31 March 2002 last revised 10 November 2008
For more information, please contact Henry M. Walker at walker@cs.grinnell.edu.