Version control with CVS
A revision control system is a class of tool that has been developed over many years to help manage large team programming projects. It has also turned out to be fundamental to the success of virtually all open-source projects, because open-source teams are almost always distributed globally via the Internet. So even if there are only two people working on a project, they benefit from using a revision control system.
The defacto standard revision control system for open-source projects is called Concurrent Versions System (CVS), available at www.cvshome.org. Because it is open-source and so many people know how to use it, CVS is also a common choice for closed projects. Some projects even use CVS as a way to distribute the system. CVS has the usual benefits of a popular open-source project: the code has been thoroughly reviewed, it’s available for your review and modification, and flaws are rapidly corrected.
CVS keeps your code in a repository on a server. This server may be on a local area network, but it is typically available on the Internet so that people on the team can get updates without being at a particular location. To connect to CVS, you must have an assigned user name and password, so there’s a reasonable level of security; for more security, you can use the ssh protocol (although these are Linux tools, they are readily available in Windows using Cygwin—see www.cygwin.com). Some graphical development environments (like the free Eclipse editor; see www.eclipse.org) provide excellent integration with CVS.
Once the repository is initialized by your system administrator, team members may get a copy of the code tree by checking it out. For example, once your machine is logged into the appropriate CVS server (details of which are omitted here), you can perform the initial checkout with a command like this:
cvs –z5 co TIJ3
This will connect with the CVS server and negotiate the checkout (‘co’) of the code repository called TIJ3. The ‘-z5’ argument tells the CVS programs at both ends to communicate using a gzip compression level of 5 in order to speed up the transfer over the network.
Once this command is completed, you’ll have a copy of the code repository on your local machine. In addition, you’ll see that each directory in the repository has an additional subdirectory named CVS. This is where all the CVS information about the files in that directory are stored.
Now that you have your own copy of the CVS repository, you can make changes to the files in order to develop the project. Typically, these changes include corrections and feature additions along with test code and modified buildfiles necessary to compile and run the tests. You’ll find that it’s very unpopular to check in code that doesn’t successfully run all its tests, because then everyone else on the team will get the broken code (and thus fail their builds).
When you’ve made your improvements and you’re ready to check them in, you must go through a two-step process that is the crux of CVS code synchronization. First, you update your local repository to synchronize it with the main CVS repository by moving into the root of your local code repository and running this command:
cvs update –dP
At this point, you aren’t required to log in because the CVS subdirectory keeps the login information for the remote repository, and the remote repository keeps signature information about your machine as a double check to verify your identity.
The ‘-dP’ flag is optional; ‘-d’ tells CVS to create any new directories on your local machine that might have been added to the main repository, and ‘-P’ tells CVS to prune off any directories on your local machine that have been emptied on the main repository. Neither of these things happens by default.
The main activity of update, however, is quite interesting. You should actually run update on a regular basis, not just before you do a checkin, because it synchronizes your local repository with the main repository. If it finds any files in the main repository that are newer than files on your local repository, it brings the changes onto your local machine. However, it doesn’t just copy the files, but instead does a line-by-line comparison of the files and patches the changes from the main repository into your local version. If you’ve made some changes to a file and someone else has made changes to the same file, CVS will patch the changes together as long as the changes don’t happen to the same lines of code (CVS matches the contents of the lines, and not just the line numbers, so even if line numbers change, it will be able to synchronize properly). Thus, you can be working on the same file as someone else, and when you do an update, any changes the other person has committed to the main repository will be merged with your changes.
Of course, it’s possible that two people might make changes to the same lines of the same file. This is an accident due to lack of communication; normally you’ll tell each other what you’re working on so as not to tread on each other’s code (also, if files are so big that it makes sense for two different people to work on different parts of the same file, you might consider breaking up the big files into smaller files for easier project management). If this happens, CVS simply notes the collision and forces you to resolve it by fixing the lines of code that collide.
Note that no files from your machine are moved into the main repository during an update. The update brings only changed files from the main repository onto your machine and patches in any modifications you’ve made. So how do your modifications get into the main repository? This is the second step: the commit.
When you type
cvs commit
CVS will start up your default editor and ask you to write a description of your modification. This description will be entered into the repository so that others will know what’s been changed. After that, your modified files will be placed into the main repository so they are available to everyone else the next time they do an update.
CVS has other capabilities, but checking out, updating, and committing are what you’ll be doing most of the time. For detailed information about CVS, books are available, and the main CVS Web site has full documentation: www.cvshome.org. In addition, you can search on the Internet using Google or other search engines; there are some very nice condensed introductions to CVS that can get you started without bogging you down with too many details (the “Gentoo Linux CVS Tutorial” by Daniel Robbins (www.gentoo.org/doc/cvs-tutorial.html) is particularly straightforward).
