The Concurrent Versions System (CVS) provides a framework where multiple users can edit the same files. As you can imagine, if a group of users edits the files in a single directory, chaos would reign. Using CVS, however, a group of people can safely work on the same set of files. CVS keeps the master copy of the files, and it records who changed what and when in a central repository. If conflicts arise, CVS lets you know. CVS is often used so that programmers can share code, but it also works well for documentation.
In most cases, each set of files that make up a package or project is stored as a module on the CVS server.
When working with files from CVS, you checkout a copy of the module on your local file system. After modifying one or more files, you commit them back to the central CVS repository server.
With CVS you may edit a file without first getting permission or locking the file. The concurrent part of the CVS name comes from its ability to allow several different people to edit different parts of the same file. As long as none of the changes overlap, CVS can correctly record their changes. In case of duplicate changes, they are clearly marked in the files and the authors must resolve the issue among themselves.
When you commit changes, only changes to files the server knows about are committed. In other words, if you created a file in your local checkout of a module, the new file is not automatically uploaded to the server. You must add the file to the repository and then commit it. If you remove a file from your local checkout of a module, you must specify that you want to remove it from the repository on the CVS server and then commit the removal of the file.
The specific commands to perform these actions are discussed in Section 10.4, “Basic CVS Commands”.
If someone has modified the file between the last time you grabbed the file from CVS and when you try to commit a change, CVS will try to merge the changes into the master copy of the CVS server. If the content you changed is in a different location in the file than the content changed by someone else, chances are, the commit action will go through without a conflict. If someone modified the same content as the content you just changed and tried to commit, you will see a message that a file conflict has occurred. Thus, you need to update your files frequently. It is a good practice to update them right before you start modifying a file. Refer to Section 10.4.8, “Resolving Conflicts” for instructions on resolving conflicts.