CVS Basics

Introduction · CVS and SSH · Basic Commands

Introduction

Concurrent Versions System (CVS) is a version control system, i.e., it allows multiple users to share a common repository containing versions of code. The fact that CVS keeps versions of code allows users to get the latest version, added by any other user, as well as to retrieve any previous versions, if there's a need.

CVS keeps the repository in a server, which can be accessed by remote CVS clients. CVS has an internal access method, which is not very secure. Most machines nowadays allow or enforce connection via a secure shell. CVS permits the use of an external access method, such as ssh. To do so, you have to define the environment variable CVS_RSH and specify the external access method when checking out the code for the first time. Checking out code creates a copy of the latest version of code (the module or directory you specify and all the subdirectories). This becomes your working copy. You may change files in your working copy as much as you want. When you're ready to place it in the repository (because it's ready to be shared, or because you want to keep the current working version, etc), you have to check in code. When you do this, cvs automatically verifies if there has been any change since you downloaded the code, includes the changes in your code, and adds your changes to the repository. If the changes made to the repository and your changes conflict, cvs warns you about that, and will not let you check in code until you fix the conflict.

When you check out code ("download" or "get the latest version"), cvs creates a directory named "CVS" in each of the directories it checks out, containing files that CVS uses for administrative purposes. These are text files containing the location of the repository, the relative location, in that repository, of the current directory, and the list of files and respective version numbers. CVS uses all this information to keep track of where to put things in the repository, and what version it should compare your files to.

Since check out is the first essential step when using cvs, the first instruction should be how to check out code. We will assume you have full access to the server where the repository is located. For the sake of example, let us say the server where the CVS repository is located is bubbler.speech.cs.cmu.edu, and the user name in that machine  is "dknuth". You check in code by doing:

  1. Define the environment variable CVS_RSH to ssh. If you do not, the check out is probably going to time out. Also, make sure that you either give the full path or have the location of ssh in your PATH. In several different OSes, you do this:
  2. Check out the code
    cvs
    -d:ext:dknuth@bubbler.speech.cs.cmu.edu:/usr0/cvsroot co argus

It may help if we explain the structure of the line above. The "-d" option specifies a directory location, where the repository is. This location has several fields separated by ":". "ext" specifies an external access method. The next field specifies the username and the machine. This is used by ssh to login to the server. The following field, "/usr0/cvsroot", specifies the location, in the server, of the CVS repository. Finally, the next element in the line is the command. CVS per se does nothing. You always need a command that refers to the action to be taken. In this case, "check out", or "co" for short. Check out requires another argument, in this case "argus", and that's the module. The module is the top level directory of a project. When you check out code as above, you create a directory named argus in your current directory.

For other commands, please keep reading.

top

CVS and SSH

Since CVS uses ssh for connection, it may be worthwhile talking about ssh. Ssh (Secure shell) provides a means for secure connection to a remote machine by encrypting some of the information transmitted (e.g. the password). It also allows the creation of keys. Keys are a mechanism which allows you to login without having to type a password. In  this sense, it's more secure to use keys. However, you need to be careful with where you leave your keys, as you do with your home's and car's.

The concept is similar to actual keys: if the keys and the door lock match, you can get in. If not, bad luck. This is how it works. On your local machine (which we are going to call "MyDesktop"), you create the keys. This will generate two files with random numbers: one of them containing information that will remain in MyDesktop, and the other which you will copy to the remote machine (which we will call "OurServer"). When you try to login from MyDesktop to OurServer, OurServer sends back the key you previously copied. If MyDesktop decodes the key and matches it against the information it has, then it sends the positive result to OurServer, which happily accepts the connection. If the match doesn't happen, OurServer gives you an alternative before denying the connection: you can type your password. Notice that in the first case you logged in without a need to type your password. You just typed "ssh OurServer", and the machines exchanged information, transparently to you.

Now you are thinking, "I'm tired of typing passwords, how can I do that?". CMU's servers use ssh protocol 1. This will affect the key creation and the files you need to copy. Anyway, here you are the step by step instructions:

  1. On your ssh-enabled machine, MyDesktop, type "ssh-keygen -t rsa1". This will create two files, $HOME/.ssh/identity and $HOME/.ssh/identity.pub. Notice that the directory .ssh is hidden in unix. Also, and this is very important: make sure that only you have access to $HOME/.ssh! In a normal unix filesystem, this is guaranteed by setting the permissions to rwx------, which is the default when .ssh is created.
  2. Keep $HOME/.ssh/identity on MyDesktop, and keep it safe. Anyone with this file can login to any machine where you placed your keys without typing a password.
  3. Copy $HOME/.ssh/identity.pub to OurServer, to the directory named "$HOME/.ssh". If the file $HOME/.ssh/authorized_keys exists, append identity.pub to it. If not, just rename $HOME/.ssh/identity.pub to $HOME/.ssh/authorized_keys.
  4. You should now be able to ssh to OurServer from MyDesktop without using your password.
  5. If your home directory is on afs (Andrew File System), please read on.

The issue about home directory on AFS may affect only students with CMU CS or Andrew account. If your home directory is on AFS, you need Kerberos authentication (at least at CMU) to access files. When you login with keys, however, the shell does not do any Kerberos authentication. Therefore, AFS will not let you access the directory $HOME/.ssh, and your login will fail. Moreover, since permission on AFS are set on a directory basis and not on a file basis, your directory .ssh may be accessible from outside if you are not careful enough. In any case, considering that you need to avoid the need for Kerberos authentication, you have two possible solutions: ask the instructor to change your home directory to a local directory on the machine you want to login to (not the easiest solution); or you can create a directory .ssh in any networked filesystem and create a link from your AFS home directory to that copy. The latter has the advantage (or disadvantage, depends on you) that you will be able to login to any machine without typing your password, provided that your home directory is on AFS. The steps:

  1. Create the directory .ssh on a networked local directory, e.g. mkdir /net/AnotherServer/usr0/dknuth/.ssh
  2. Make sure the permissions are set right, chmod 700 /net/AnotherServer/usr0/dknuth/.ssh
  3. Create a link from your home directory to .ssh, ln -s /net/AnotherServer/usr0/dknuth/.ssh ~/.ssh

You should now be able to login from MyDesktop to OurServer, and you will be able to perform CVS operations without the need to type your password.

top

Basic Commands

Here we present a list of basic CVS operations. The operations are usually recursive, that is, they occur in the current directory and all its subdirectories. Additionally, if you do not specify a file, CVS will operate on all files.Exceptions are noted. This list is by no means exhaustive.

  1. Check out: cvs -d:ext:username@server:/usr0/cvsroot co <module>
  2. Commit (add changes to repository): cvs commit or cvs commit <filename>
  3. Add directory, operation not recursive (beware that you are not able to remove directories if you do not have access to the repository itself): cvs add <dirname>
  4. Add file, operation not recursive: cvs add <filename> followed by cvs commit <filename>
  5. Remove file: rm <filename> then cvs remove <filename>
  6. Show differences between your copy and the version from where it came: cvs diff <filename>
  7. Update existing directories: cvs update
  8. Update directories, creating directories that have been added since you checked out: cvs update -d

top