Concurrent Versions System (CVS)

Introduction

I will treat this as a check-off lab. I want you to learn enough about CVS (Concurrent Versions System) so that you can make productive use of it in your projects. To that end, I will have you work with your partners to set up a repository, create a project in that repository for the music scheduling system, and use basic CVS commands to work concurrently on that project.

Resources

If you want to know more about CVS, please look at the book Pragmatic Version Control, by David Thomas and Andrew Hunt, which is in the monitor room next to the computer lab. That book gives a good overview of version control using CVS. It also gives a number of standard commands, which they call recipes, which you can add to your repertoire. Additionally, here are two links to CVS websites:

Tasks

You first need to create a repository where projects can be stored (Pragmatic Version Control calls this directory a sandbox). Since your team only needs one repository, one of you should open a shell, go to your home directory, and issue the following command:
```
    cvs -d ~/sandbox init
  
```
This will create a directory called sandbox and put various system files in a subdirectory called CVS. You should not do anything directly to your sandbox. It will be manipulated through the various CVS commands. Note: be sure to make this directory read/write accessible to others.
By the way, the general form of a CVS command is:
```
    cvs <global options> command <options and arguments>
  
```
using the notation from Pragmatic Version Control. In particular, the CVS command used above is init, and the global option is -d ~/sandbox, which tells where the repository should be located. You can get more information about the commands starting on page 139 of Pragmatic Version Control.
You next need to create your musicsystem project. To do this, first go to the directory that contains your project; in the following, I am going to assume that that dirctory is called musicsystem. Before issuing the following command, it would be best to be sure that your directory is in the basic form you want it, and that it doesn't contain extraneous files (such as the ~ files that emacs creates for backups). Once this is done, issue the following command:
```
    cvs -d ~/sandbox import -m "Initial import" musicsystem musicsystem initial
  
```
This makes CVS install the files and directories (and recursively their files and directories) in the repository with under name musicsystem. After issuing this command, do a directory listing on ~/sandbox, and you should see a directory called musicsystem which (more or less) contains the files in your source directory. (I say more or less since, for example, the GNUmakefile is now GNUmakefile,v. This is how it keeps the various versions of the file as it is being revised.)
Check-off: Show me the repository you have created, as well as the musicsystem project in it.
Now each team member should check out the project for their own usage. Each team member should create a work directory that will contain the projects you are working on. Go to that directory and issue the following command (Note: the instance of user in this command should be replaced by the username of the team member that has the repository):
```
    cvs -d ~user/sandbox co musicsystem
  
```
This will create a subdirectory called musicsystem of your work directory, which is identical to the directory that you used to create your Music System project, except that it has some additional CVS files and directories which it uses to maintain necessary information. In particular, each directory has a subdirectory called CVS which knows where the repository is located. (You may look at these CVS directories, but do not change them directly; your CVS commands will work with them.) In particular, whenever you issue a CVS command from your project or its subdirectories, you will no longer need to include the global option -d ~/sandbox.
Check-off: Each team member should show me their copy of the project.
One team member should open some file you would be working on and make some changes to it. You will next issue the command that will check in that file. Actually there are several ways to do this. One way is to go to the project directory or the directory containing the edited file, and issue the following command:
```
    cvs commit -m "Minor changes"
  
```
This will commit all changed files in the current directory (and recursively below) to the project.
You can see what changes you have made by issuing the following command:
```
    cvs log file-name
  
```
where file-name is the name of the file (including path, if necessary) that you edited. This will give information about the various revisions of that file.
Using this information, you can see exactly what you have changed. Do this by issuing the following command:
```
    cvs diff -r1.1 -r1.2 file-name
  
```
This will do a "diff" on the two revisions (1.1 and 1.2), and report the lines of the two versions that differ.
Check-off: Show me the output of this diff.
Finally, someone else in the team should get the changes you have made. This is done by going to the topmost project directory (under your work directory), and issuing the following command:
```
    cvs update
  
```
This should now update the files in your project directory, reflecting the changes the other team member made.
Check-off: Show me this file.

Final comment

There is a lot I am leaving out here. I encourage you to read through the first three chapters of Pragmatic Version Control which, I remind you, will be stored in the monitor room next to the lab. This book will tell you how to interact remotely with CVS.