CVS follows the copy-modify-merge model. Pragmatically, it works like this. A person checks out a copy (copy = a folder structure of documents) of the master copy and modifies it. Once the modifications are complete, the copy is merged (committed) back into the master copy. It sounds simple, but since humans are involved, it really isn’t. There are all sorts of scenarios for which the software must account.

For example, Developer A checks out a copy of the repository (CVS terminology for master copy). At the same time, Developer B checks out a copy of the same repository. Developer B then makes changes to his revision (cvs terminology for a copy of the master) and then commits these changes back to the repository. Developer A now has an outdated copy of the repository. Or, in other words, the copy that Developer A has could possibly be in conflict with the repository. I say possibly because Developers A and B may have changed completely different documents in the repository. If they changed the same content, then there will be a conflict – if they didn’t, then the merge of their revisions back into the repository will have no conflicts.

Now lets just say that Developers A and B did in fact change the same document and same content in the document. Now, when Developer A goes to commit his revision, it will be in conflict with the repository. So Developer A has to resolve the conflicts. This same exact scenario can happen in another way. Say that before committing his changes, Developer A tries to update his revision by updating it with the most recent copy of the repository. In doing so, Developer A is merging the changes Developer B already committed into the repository into his revision. Again, Developer A must resolve the conflicts in order to update his revision.

This is CVS in a nutshell. Conceptually, this is easy to grasp, but in practice, it can be confusing. I recommend memorizing the following terms, and always returning to the base concept I just explained.

Revision – A committed change in the history of a file or set of files. A revision is one “snapshot” in a constantly changing project.

Repository – The master copy, where CVS stores a project’s full revision history. Each project has exactly one repository.

Working copy – The copy in which you actually make changes to a project. There can be many working copies of a given project; generally each developer has his or her own copy.

Check out – To request a working copy from the repository. Your working copy reflects the state of the project as of the moment you checked it out; when you and other developers make changes, you must commit and update to “publish” your changes and view others’ changes.

Commit – To send changes from your working copy into the central repository. Also known as check-in.

Log message – A comment you attach to a revision when you commit it, describing the changes. Others can page through the log messages to get a summary of what’s been going on in a project.

Update – To bring others’ changes from the repository into your working copy and to show whether or not your working copy has any uncommitted changes. Be careful not to confuse this with commit; they are complementary operations. Mnemonic: update brings your working copy up to date with the repository copy.

Conflict – The situation when two developers try to commit changes to the same region of the same file. CVS notices and points out conflicts, but the developers must resolve them.