About source code version control with CVS
The Concurrent Versions System (CVS) is a version control system for keeping track of all modifications to project source code files. CVS is widely used in both open source and proprietary software development projects, and is generally considered to be the best freely available, full-featured version control tool. Two special features make CVS particularly suited to collaborative development across the Internet:
- CVS allows multiple developers to edit their own working copies of files simultaneously, then deals with combining all the changes and notifying developers when there are conflicts.
- Remote access to source code file repositories. Developers who are project members can obtain and modify project files from virtually anywhere.
CVS is a client-server system. The CVS repository is maintained on a web server; clients run on users' machines and connect to the server via the Internet. You must have a CVS client on your local machine to access the CVS server for projects hosted on this site. Clients are available for nearly all platforms including: Unix, Windows, Macintosh, and any Java-based platform. This documentation includes instructions for running CVS in a Unix shell or WinCVS.
As a project member, CVS allows you to:
- Check out source files and directories
- View differences between versions of files
- View change log history and comments
- Commit changes made in your local copy of the source files to the main source code repository
- Update your local project files when you want to remain in sync with changes committed by other project members
If you are new to CVS, one the best ways to learn about it is simply to jump in and begin using it. When you click on the Source Code link in the Project Resources tool bar, you can follow the instructions in that page for checking out your own working copy of a particular project's source files. You can also find further, more specific information in this site's three-part CVS tool document, Using command-line CVS or Using WinCVS.
For those looking for a step-by-step orientation of CVS, A Day with CVS, excerpted from the online version of Karl Fogel's book, Open Source Development with CVS, is highly recommended. Much of the CVS help information on this site comes from this authoritative source.
Suppose you are interested in joining an open source project but you are unknown to the project owner and other project members. The logical first step is requesting to join the project, of course, but you can take some basic preliminary steps toward establishing yourself as a potential contributor, thereby raising the likelihood of gaining membership approval.
- Subscribe to and regularly read the relevant mailing lists so that you know what is going on in the particular area of development you are interested in.
- When you post your first message to a discussion mailing list, introduce yourself and include the following:
- who you are
- a few words on your background
- your interest in the project, and
- what you would like to see happen with the project.
- Make sure you have browsed through the existing source code and understand what it is doing and how. If something is poorly documented, confusing, or you just can't grasp what is going on, ask on the associated mailing list for a summary.
- Mention in writing that you understand the licensing governing the code that you will be working on, and your agreement that any changes you contribute are your own and these can be incorporated under that license.
- Request project membership to gain cvs check-in permissions on an area of the code base, and explain what sorts of things you are interested in doing with it. You will need to communicate frequently with the people who already maintain that area of code, so make sure there is consensus about what you should be working on.
- When the project owner approves your project membership, you will get a CVS check-in account, probably restricted to a certain area. Make sure you understand which CVS branch you are supposed to be working on!
- Submit some patches to establish that you know what you are doing.
- When you make modifications and enhancements, seek feedback and discussion about these on the associated mailing lists.