CVS (Concurrent Version System)



CVS (Concurrent Versions System)

CVS is a version control tool that allows you to record the history of your (software) source files in a centralised repository. In the software development process, you often need to incrementally refine your source files, so each source file is likely to have multiple versions. Being able to keep track of these different versions is paramount, especially when the new version does not work the way you expected and retrieving an old version of the source file is necessary.

There are many version control tools available. The very popular version control tool is perhaps SCCS (Source Code Control System) that runs on Unix. In the B337 unit, we will use CVS which has been installed on machines in the lab. CVS is free and is downloadable from . You should use a version control system, such as CVS, when developing your software projects (assignments).

The basic operations supported by CVS are: importing source files (a Java package, for example) into the cvs repository; checking out files from the repository for updating; examining status of source files being updated; finding out difference between versions, etc. CVS also allows the repository to be on a remote machine so long as that machine is accessible via NFS (network file system), eg. the repository could be on drive H while the source files checked out from the repository were saved onto your harddisk (drive C) for fast edition and enhancement. The repository could also sit on a server and multiple software developers could access this repository from the client machines. CVS provides a locking mechanism so that a read access from the repository is pending while a write access to the repository by another developer is active.

More details on CVS can be found in the c:\Program Files\cvs\cvs.html or c:\cvs\cvs.html file. You may not be able to understand that html file fully because most of the issues discussed there are relevant for the Unix environment only while other issues are for system administration. I have therefore compiled below a brief description on how to use CVS and the set up of environment variables, path, etc. that are required for CVS to function.

I have made the assumption that the CVSROOT repository is on drive C and the working directory of the source files is also on drive C. Please refer to the last section of this text for the set up of environment variables if

i) drive H (your home directory after you are logged on) is the desired drive for the repository and working directory, or

ii) drive H has the repository while the working directory is on drive C (for fast source file access, for example).

Environment variable

You will need to set up the environment variable CVSROOT to point to a directory. For instance, putting the line

SET CVSROOT=:local:c:\cvs_root

in your c:\autoexec.bat file will set the c:\cvs_root to be the master source repository directory. Note that you must have the string :local: immediately before the absolute path name.

Search path

Suppose that you have cvs.exe installed on your c:\cvs directory. You should then include c:\cvs in the search path, i.e. putting the line

SET PATH=%PATH%;c:\cvs

in c:\autoexec.bat.

Note that to have the environment variable and path effective, you will need to reboot your PC or type c:\autoexec in a MS-DOS prompt window. For the latter operation, the setting will be effective in that MS-DOS prompt window only. If you are using the machines in the IT lab then you can skip this process since the search path has already been set up.

Initialisation

Do the following initialisation (assuming that you have created the master source repository directory c:\cvs_root above) in an MS-DOS prompt window:

cvs –d :local:c:\cvs_root init

The command above would create the subdirectory CVSROOT under c:\cvs_root. The CVSROOT subdirectory contains administrative files for cvs. The other subdirectories contain the actual user-defined packages (each subdirectory maintains a software package whose version you want to control and monitor).

Some commonly used cvs commands

Now suppose that you have a package of Java units, say the files HelloWorld.java and Greetings.java, under the c:\myJavaProgs directory. You are about to do some modification to any one of these files and would like to be sure that you could retrieve the current version of HelloWorld.java and Greetings.java back if something drastic happens in the modification process.

Importing a package into the cvs repository

You import the entire package to the cvs repository by typing:

cd c:\myJavaProgs

cvs import –m “initial import” myJavaProgs myVendorTag start

In the above command, “initial import” is the message that you specify for the importing, myJavaProgs is the package name, myVendorTag is the vendor tag, start is the release tag. The last two arguments may fill no purpose in this context, but since cvs requires them they must be present.

If the above cvs command was successful then the messages returned by cvs would be

N myJavaProgs/Greetings.java

N myJavaProgs/HelloWorld.java

No conflicts created by this import

If the –m flag was omitted in the above cvs command, then an editor (default editor is Notepad for Windows) would appear in which you could type the brief description for the reason of importing.

1. Checking out the package for updating/edition

You must check out the package before proceeding to step 3 below for the editing/updating. This step will allow you to commit the new version (after your editing/updating) of the Java units to the repository. To check out the package, type:

cvs checkout myJavaProgs

A subdirectory myJavaProgs would be created in the current directory where the command was invoked. All the Java units (in this case, HelloWorld.java and Greetings.java) and a subdirectory CVS (cvs uses it for bookkeeping tasks) would be generated in the myJavaProgs subdirectory. It therefore depends on from where you invoke the command. If you type

cd c:\

before the above cvs command, then the original version of HelloWorld.java and Greetings.java would be overwritten. However, this is not a problem as the files have not been updated since the initial import.

2. Editing/updating one or more Java units in the package

You can now proceed with your update/edition on the Java unit(s) in the package. If you have tested your modification thoroughly, you can commit the updated Java unit(s) to the cvs repository (see step 4). If your update introduced bugs into the package then you might want to discard the update and roll back to the previous version (see step 6).

3. Committing the updated Java units to the cvs repository

Suppose that you have now updated both HelloWorld.java and Greetings.java and have verified the correctness of your update. To commit the updated Java unit(s) to the cvs repository, type:

cvs commit Greetings.java HelloWorld.java

or

cvs commit *.java

The system should respond with

c:\cvs_root/myJavaProgs/Greetings.java,v ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download