include("site.inc"); $template = new Page; $template->initCommon(); $template->displayHeader(); ?>
The Concurrent Versions System (CVS) provides a framework for collaborative revision. Without such a framework, a group of users editing files in a single directory would cause chaos. Using CVS, however, a group of people can safely work on the same set of files. The CVS server keeps the master copy of the files, and it records all changes and associated data, such as authors and time, in a central repository. If conflicts arise, CVS advises the users. Programmers often use CVS to 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. As long as none of the changes overlap, CVS can correctly record their changes. When duplicate changes occur, 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 8.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, the commit action will likely 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 8.4.8, “Resolving Conflicts” for instructions on resolving conflicts.