Swayam has a master’s degree in computer engineering. He has been working in information technology for several years, concentrating on areas such as operating systems, networking, network security, electronic commerce, internet services, LDAP and web servers. He can be reached at swayam.prakasha (at) gmail (dot) com
Sometimes there will be a need to maintain historical versions of the software that we develop and also to co-ordinate the development activities between numerous programmers located in various parts of the globe. When multiple people are working on a software project, it is also important that changes need to be synchronised so that one developer’s work will not overwrite another’s. When we make several releases of a specific project (product or service), we may be interested in retrieving the source code corresponding to a specific release. Concurrent Versions System (CVS) is used as a source code repository in the majority of software projects. The basic idea behind CVS is that whenever a developer makes changes to the source, these changes are checked into the CVS repository. The repository holds the master copy of the code. It also contains details representing historical information about various files (ie revision history). The repository will be normally located on a networked environment somewhere. With CVS, one can obtain the current version of the code or any version committed in the entire history of the code. We will be able to identify these versions on a file-by-file basis. We can also retrieve differences between any two versions of the code.
The first thing that we need to do as far as CVS is concerned is to establish a repository. The repository holds the data from the CVS program itself, which consists of files, their source code and entire history. When we commit changes, the repository gets updated and when we check out code, it comes from the repository.
CVS is one program, but it can perform many different actions – such as updating, committing and diffing. So the user needs to specify which action needs to be performed when he invokes CVS.
Another feature of CVS is that it can enable remote access to the repository. It means that each and every developer can work on a separate machine, but each one of them will be able to commit and fetch their code (ie check out their code) from a single centralised repository. CVS handles network details completely and transparently. CVS can be set up in a number of ways to allow network access. One method is to use programs such as rsh or ssh. ssh is a popular way as it not only uses a secure public key authentication system, but also encrypts the data while in transit.
Before we invoke CVS for the first time, we need to set up the environment. This means that we need to set the value of a specific variable, CVSROOT. Assuming that we will have a directory ‘cvsroot’ in our home directory, we can set the value of this variable with the following command.
$ export CVSROOT=$HOME/cvsroot
It is best practice to add the above line to your ‘.profile’ file, such that it will be automatically set whenever you log in.
$ echo $CVSROOT
The first line above tries to display the value of the variable that was set earlier, while the second line displays its value (where /usr/home is the HOME directory).
The next step is to log in to the CVS server. Thus the developer needs to have a valid set of user ID and password.
The most common method of accessing the CVS server is known as the ‘pserver access method’ (pserver stands for password-authenticated server).
$ cvs -d pserver:firstname.lastname@example.org:/usr/home/cvs login
In the above statements, the long path following the ‘-d’ option tells CVS to use the pserver access method, with the username john and on the server mycvs.com, having a CVS repository at /usr/home/cvs.