To check out a branch version, you use the -r (revision) option:
cvs co -P -rcal2004_2 calibre/TDopc

The Checked-out Working Directory (the "Sandbox")

CVS is designed to allow several people to work on a project at once without bothering each other (that's the "Concurrent" in Concurrent Versioning System) so it doesn't perform locking the way older systems such as RCS do.

As an example of the typical use of CVS, here is a directory that was checked out and fiddled with awhile ago, but another person has made changes in the meantime.

cvs status | grep '^File' gives this output: File: app.c Status: Up-to-date File: cleanup_tst Status: Locally Modified File: compare Status: Up-to-date File: dofile Status: Needs Patch File: litho.in Status: Needs Merge File: litho.svrf Status: Up-to-date File: mkbaseline Status: Up-to-date File: setup_tst Status: Needs Patch File: test.oas Status: Up-to-date File: xor.svrf Status: Up-to-date

cvs -n -q update gives the short form: M cleanup_tst U dofile M litho.in U setup_tst ? litho.transcript ? xor.transcript ? xor_result.oas

In TkCVS, it looks like this:

Let's look at what the different statuses mean.
Needs Patch:  dofile and setup_tst have changed in the repository.  All that's needed is to update them, which will put the latest version in the current "sandbox."
Needs Merge:  litho.in has changed in one way in the repostiory, and it has been edited a different way, but not committed, in the current directory.  An update is needed here, too.  When updating, CVS will merge both sets of changes into the local file.
Locally Modified: cleanup_tst has changed in the local "sandbox" but not in the repository.

After doing  cvs update we have

cvs status | grep '^File' File: app.c Status: Up-to-date File: cleanup_tst Status: Locally Modified File: compare Status: Up-to-date File: dofile Status: Up-to-date File: litho.in Status: File had conflicts on merge File: litho.svrf Status: Up-to-date File: mkbaseline Status: Up-to-date File: setup_tst Status: Up-to-date File: test.oas Status: Up-to-date File: xor.svrf Status: Up-to-date

cvs -n -q update M cleanup_tst C litho.in ? litho.transcript ? xor.transcript ? xor_result.oas

The "Needs Patch" files are up-to-date now, but CVS could not automatically merge the two sets of edits to litho.in, because the same line was changed in different ways by the two edits.  The "common ancestor" of the two files has been saved as the hidden file .#litho.in.1.1, and the current litho.in contains conflict markers, ie.

<<<<<<< litho.in
aspect 4.0
siteinfo AERIAL -num 8
=======
siteinfo AERIAL -num 10
>>>>>>> 1.2

Unless you simply want to abandon your changes (cvs update -C litho.in ) you must edit the file and resolve the conflict manually.  An easy way to do it is with tkdiff:
tkdiff -conflict litho.in


After resolving the conflict and saving the file, litho.in has a status of "Locally Modified."  Now you can check in (commit) the changes you want to keep:
cvs ci cleanup_tst litho.in
Then "cvs status" will show everything up-to-date.

Important CVS helps you checkpoint revisions, but the best policy to head off problems is old-fashioned communication.  If you check in changes to a suite you know someone else also works on, it's common courtesy to inform them when you make substantial changes.  That's especially important if you add or remove directories, because the other person won't be alerted to that by CVS. You'll have to notify them that they should do cvs update -d -P to get the new directories (-d) and remove the obsolete ones  (-P).