Editing Concurrent Versions System (section)

== Operation ==

CVS labels a single project (set of related files) that it manages as a ''[[module (programming)|module]]''. A CVS server stores the modules it manages in its ''[[information repository|repository]]''. Programmers acquire copies of modules by ''checking out''. The checked-out files serve as a ''working copy'', ''sandbox'' or ''workspace''. Changes to the working copy are reflected in the repository by ''[[commit (data management)|committing]]'' them. To ''update'' is to acquire or ''[[merge (revision control)|merge]]'' the changes in the repository with the working copy.

CVS uses a [[client–server]] architecture: a server stores the current version(s) of a [[project]] and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. CVS servers can allow "anonymous read access",<ref name="anoncvs" /> wherein clients may check out and compare versions with either a blank or simple published password (e.g., "anoncvs"); only the check-in of changes requires a personal account and password in these scenarios. Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or ''checking in'') their modifications to the server. To avoid conflicts, the server only accepts changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when an [[edit conflict]] arises between a checked-in modification and the yet-unchecked local version of a file. Clients can also use the "update" command to bring their local copies up-to-date with the newest version on the server. Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project (e.g.: based on a given date). If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the server writes a user-supplied description line, the date and the author's name to its [[data logging|log]] files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's <code>loginfo</code> file, which can trigger email notification or convert the log data into a Web-based format.

CVS can also maintain different "branches" of a project. For instance, a released version of the software project may form one branch, used for bug fixes, while a version under current development, with major changes and new features, can form a separate branch. CVS assumes that the majority of work takes place on the trunk, and that branches should generally be short-lived or historical. When used as designed, branches are easily managed and branch operations are efficient and fast.<ref name="Collins-Sussman" /><ref name="West" />