Quick & Dirty CVS Intro

All the info from this page was taken from Open Source Development with CVS, an excellent book that is available online for free (mostly - you don't really need to know the stuff that's not free though). If you have some time, I highly reccomend reading the first few chapters of that book (especially if you're a team leader).

If you want to know how CVS works, read the first few chapters of that book. This document is a very quick & dirty throwdown of what CVS is and how to use it. I'll be making references to the book throught this document, so if you don't understand what this is saying, check out the book - he does a much better job explaining stuff than I do.

Sections

• What is CVS?
• The two basic actions: checkout and commit

What is CVS?

CVS is a Concurrent Versioning System. It's source code control.

CVS serves two primary purposes:

• It is a central storage location for code, ensuring that every member of a team always has the lastest version of each file.
• It keeps an entire history of changes made, allowing you to revert to any version at any time.

All of the source for a project sits on the central CVS server, in the repository. Nobody keeps code on their computer when they're not working on it.

When Alice wants to start working on the project, she download the latest version of the project from the CVS server, or checks out the project, with a CVS client. She codes for a while, and after she pulls all her hair out, applies her changes to the server, or commits the project.

Later, when Bob wants to code, he checks out the project from the CVS server. The code that he gets will have the changes that Alice made, even though he might not know that Alice worked on it.

For more details on what CVS is or the advantages of using CVS, see the Basic Concepts section of the CVS book.

The Two Basic Actions: checkout and commit

When working with CVS, 90% of your actions will be either checkouts or commits.

Checking Out

cvs checkout module_name

Here's an example where I checked out the module "test":

C:\Documents and Settings\Ninji\Desktop\code>ls

C:\Documents and Settings\Ninji\Desktop\code>cvs checkout test
cvs server: Updating test
U test/code.c
U test/readme.txt

C:\Documents and Settings\Ninji\Desktop\code>ls
test

C:\Documents and Settings\Ninji\Desktop\code>cd test

C:\Documents and Settings\Ninji\Desktop\code\test>ls
CVS         code.c      readme.txt

When I execute the cvs checkout test command, it creates the directory "test" in my current directory, and fills it with the files from the module 'test', which are, in this case, readme.txt and code.c. You now have a working copy of the code. It also added the directory, CVS. CVS uses this to keep track of stuff. Never touch this directory. Ever. Ever ever ever ever ever. Ever.

Committing

The "log message" is a short (usually one line) description of what was changed since the last commit. If the -m switch is not applied, then a default text editor will open (depends on implementation). Then you can enter whatever you want, save the file, and exit the editor. The commit action will then continue.

If you'd like some examples, check out one of the logs from a file of Gaim. As you can see, sometimes the log messages are less than descriptive("don't ask", "hi", etc), but usually they are.

cvs commit -m "Log Message"

Here's an example, where I modified the test.c file.

That's it for now. Feel free to read some of the CVS book, especially the parts on the CVS commands diff, log, update, release, and tag. If people want, I can write a little doc on those too.