In CVS, files are never locked. Two users can check out the same file at the same time; each user has a separate copy and can edit it. Work files are always writable; once you have one, you need not type a VC command to start editing the file. You can edit it at any time.
When using RCS and SCCS, you normally use C-x C-q twice for each change; once before the change, for checkout, and once after, for checkin. With CVS, it's different: you normally use C-x C-q just once for each change, to commit the change when it is done. The work file remains writable, so you can begin editing again with no special commands.
One way to understand this is that VC does an implicit check-out when you save the modified file for the first time. VC indicates this on the mode line: the status indicator changes from `-' to `:' as soon as you save a modified version, telling you that you are not in sync with the repository anymore (see section The VC Mode Line). The file stays "checked out" until you check it back in, even if you kill the buffer and visit the file again.
If, instead, you would like to use explicit check-out with CVS, set
the CVSREAD environment variable to some value. (It does not
matter what value you use.) CVS then makes your work files read-only by
default, and VC requires you to check them out explicitly with C-x
C-q. When setting CVSREAD for the first time, make sure to
check out all your modules anew, so that the file protections are set
correctly.
VC does not provide a way to check out a working copy of an existing file in the repository. You have to use the CVS shell commands to do that. Once you have a work file, you can start using VC for that file.
CVS terminology speaks of committing a change rather than checking it in. But in practical terms they work the same way: Emacs asks you to type in a log entry, and you finish it with C-c C-c.
When you try to commit a change in a file, but someone else has committed another change in the meanwhile, that creates a conflict. VC detects this situation and offers to merge your changes and those of the other user, creating a new local version of the file, which you can then commit to the repository. This works smoothly if the changes are in different parts of the file, although it is wise to check the resulting file for semantic consistency.
However, if you and the other user changed the same parts of the file, the conflict cannot be resolved automatically. In this case, CVS inserts both variants of the conflicting regions into your working file, and puts so-called conflict markers around them. They indicate how the region looks in the respective user's version. You must resolve the conflict manually, for example by choosing one of the two variants and deleting the other one (and the conflict markers). Then you can commit the resulting file into the repository. The example below shows how a conflict region looks; the file is called `name' and the current repository version with user B's changes in it is 1.11.
<<<<<<< name User A's version ======= User B's version >>>>>>> 1.11
You can turn off use of VC for CVS-managed files by setting the
variable vc-handle-cvs to nil. If you do this, Emacs
treats these files as if they were not managed, and the VC commands are
not available for them. You must do all CVS operations manually.