(I would like to apologize for the ocassionally non-serious tone of this writeup. It does not represent my religious views. I am sorry if it is not helpful, because helpfulness was the intention behind this writeup.
ariels said this writeup is inadequate because ClearCase is *censored* not up to the task. I hope a separate writeup on that topic will appear later.)
Basic usage of CVS
Some introduction
Some terminology: Even when CVS uses file version numbers, just like RCS, you most likely don't need to care of these. The idea is that for each "release", you create a "tag". File revisions with the same tag are part of the same "release". More on this later.
Also, you have a "local copy" and the "repository". You can do whatever you want with the local copy - it is just bunch of bits. Edit it. Print it and make paper flowers out of it. Whatever. The code itself, and all of its past revisions, are stored in the repository - it may be local, or it may be on some separate server. It all depends on the case.
Also understand that this is a very brief guide - CVS has a pretty thorough manual and there was some book that is available for free on the web, but this one is a start.
I just want the get files from the "anonymous CVS server" thing!
This is what most "non-developers" who want to live on the bleeding edge want. (Warning: The developers often put the "stable" programs in easily downloadable tarballs for a good reason. =)
Typically, the Hymn "He Eats the Fruits of Distributed Development with Furiously Moving Fingers and Shredding Jaws" looks like this:
$ export CVSROOT="pserver:anonymous@cvs.example.net:/cvsroot/wherever"
$ cvs login
$ cvs checkout modulename
Now, on the other hand, if you are developing code, you may probably want to know how to do that! Read on...
Login and initial setup
First, you may need to set your CVSROOT variable and/or do cvs login. (Most of my code is either in local repository, or in SourceForge's ssh-armored repository - they have specific orders, and by default my CVSROOT variable points to the local cvs.) This all depends on the case. If you need to make a whole new repository, consult the documentation. =)
The Idea
The idea is that you make a working copy, make your changes, and check out the revision back to the repository, with comment explaining what you did.
Also note that if more than one people edit the file same time, CVS will warn about it, the conflicting code will be marked, and you need to settle that like real men/women. With fists and knives.
How your work day goes
Typically, you start the "work day" by typing something like this:
$ cvs checkout modulename
$ cd modulename
Alternatively, if you have it all copied already, you can do:
$ cd modulename
$ cvs update
As an end result, you should have an up-to-date copy of the code in the repository.
Now, code!
You can review the changes you have made by doing:
$ cvs diff
Each time you have completed a "working version", you may check out your work to CVS by saying:
$ cvs commit filename
...or, you can commit all files you have changed by leaving out the file name. Now, the thing will ask for change comments (and will pop into your favorite editor for that). Just type in some credible explanation, save and exit.
End your workday with a full commit (cvs commit).
File Management
Need to add files or directories? It's easy! Do cvs add filename. You probably will be again required to explain yourself.
Need to delete files or directories? the command is remove! (Note that whatever is removed is not removed from the repository entirely; The future may be gone, but history lives forever).
Need to rename files? Uh... er... this is where it gets clumsy! Remove and re-add. If you don't like this, wait for a non-Alpha release of Subversion or try a proprietary but nice competitor like BitKeeper something.
Tagging
Going for release? You must tag your releases. Like,
$ cvs tag release-1-0 .
This way, you can always ask for "Release 1.0" from the repository, even when you're working on 2.5 =)