Working with files
All commonly used CVS functionality is directly available in 's main view. Commands usually act on several files at once, namely all which currently selected. If the selection includes directories, its interpretation depends on the settings made under the Settings menu. For example, if Settings Commit and remove recursively is checked and you choose File Commit... while a directory is selected, then all files in the tree under that directory are commited. Otherwise, only the regular files in the directory itself are affected.
You can simply edit a file by doubleclicking on it or pressing Return. This starts the editor configured under Settings Configure Cervisia... with the file name as argument.

Adding files
Adding files to a project requires two steps: First, the files must be registered with CVS. To this end, mark all files to be added in 's main view. Then, choose File Add to repository. issues a command

cvs add
 filenames

If the operation was successful, the status column should have "Added to repository" for the added files.
In order to actually put the files into the repository, you must commit them. This procedure has an important advantage: You can commit the files together with modifications to other parts of the project. When doing this, one can easily see (e.g. in commit emails) that all these changes are part of a whole.
CVS is not designed to provide meaningful revision control for binary files. For example, merging binary files normally does not make sense. Furthermore, by default CVS performs keyword expansion string $Revision: 1.4 $) when a file is commited. In binary files, such replacements may corrupt the file and make it completely unusable. In order to switch this behaviour off, you should commit binary files (or other files, like Postscript) with a command line

cvs add -kb filenames

In , this is achieved by choosing File Add binary...

Removing files
Like adding files, removing files is done in two steps: First, the files have to be registered as removed by choosing File Remove from repository which issues the command

cvs remove -f filenames

After that, this modification to the sandbox has to be commited, possibly together with other modifications to the project.
The above command only works if the file is up-to-date. Otherwise, you get an error message. This behaviour is sensible: If you have modified the file compared to the version in the repository, or if someone else has made any modifications, you will first want to check if you really want to discard them.

Adding and removing directories
Directories are handled fundamentally different from ordinary files by CVS. They are not under revision control, i.e. you cannot tell which directories existed in the project at a certain time. Furthermore, directories can never be explicitly removed (expect by removing them directly in the repository).
As a substitute, CVS follows the convention that a directory is "not existent" in a version of the project if is is empty. This convention can be enforced by using the option -P to cvs update and cvs checkout. This option can be set in the menu Settings Prune Empty Directories On Update.
A directory can be added to the repository with the command

cvs add dirname

which is implied by the menu item File Add to repository. Note that in contrast to adding files, adding directories does not require a commit afterwards.

Commiting files
When you have made a certain amount of changes to your working copy, and you want other developers to have access to them, you 'commit' them. With a commit, you place your versions of the modified files as new revisions into the repository. A subsequent update by another developer will bring your modifications into his working copy.
In order to commit a couple of files, select them in 's main view and choose File Commit....

A screenshot of 's commit dialog
You get a dialog that shows you on the top a list of the selected files and on the bottom a log message for your changes. When you have finished the dialog, the command

cvs commit -m message filenames

is used. helps you in several ways to find a meaningful log message: First, in the file list you can double-click a file or press Return in order to see the changes you have made to the file. Second, it gives you a list of log messages you have previously used in a combo box. Third, this dialog is integrated with 's changelog editor described below.
A common error you may encounter when commiting is Up-to-date check failed. This indicates that someone has commited changes to the repository since you last updated. Or more technically, that your BASE revision is not the newest on its branch. In such a case, CVS refuses to merge your modifications into the repository. The solution is to update, resolve any conflicts and commit again. Of course, if you are working on a software project, it is normally good style to check if the program still works after you have updated - after all, there could be bad interactions between your modifications and the other modifications which break the code.
Another popular mistake results in the error message Sticky tag 'X' for file 'X' is not a branch. This happens if you try to commit a file which you have previously brought to a certain revision or tag with the command

%cvs update -r X

(which is e.g. used by the menu item Advanced Update to Tag/Date...). In such a case, the tag on the file gets sticky, i.e. further updates do not bring you to the newest revision on the branch. If you want to commit further revisions to the branch, you have to update to the branch tag before you do further commits.
With , it is quite easy to maintain a ChangeLog file that is compliant with the format layed out in the GNU coding guidelines. To use it, choose File Insert ChangeLog entry... . If a file with the name ChangeLog exists in the toplevel directory of your sandbox, this file will be loaded and you have the possibility to edit it. To this end, at the top of the file, an entry with the current date and your user name (which can be configured as described in Customizing various commands) is inserted. When you finish the dialog this dialog by clicking OK, the next commit dialog you open will have the log message set to the message you last entered in the change log.

Resolving conflicts
Conflicts may occur whenever you have made changes to a file which was also modified by another developer. The conflict is detected by CVS when you update the modified file. CVS then tries to merge the modifications commited by the other developer into your working copy. The merge fails if both your and his modifications are in overlapping parts of the file, and the CVS server issues and error message.
It is your job now to resolve these conflicts before you commit the file. CVS will refuse to commit any files with conflicts until they have been edited. Of course, you have a great amount of freedom when resolving a set of conflicts: you can for each conflict decide to take one of the two alternative versions. You can also decide that both approaches are are broken and rewrite a whole routine or the complete file from scratch.
In 's main view, files with conflicts are indicated with "Conflict" in the status column and with a red color. From the main view, you can of course resolve conflicts the traditional way: just doubleclick the file in question and edit it with your favourite editor. But you can also choose to use the dialog available via File Resolve....

A screenshot of 's resolve dialog
On the top of the dialog, you see your version the file on the left hand side and the version in the repository on the right hand side. The differences between them are marked in red color. Below these two versions, you can see the merged version which will be saved as soon as you click the Save button.
You can switch between the differing sections by pressing << and >>. In the lower middle of the dialog you can see which section is currently marked. For example, 2 of 8 means that you are currently at the second differing section of 8 total. Now can can decide section by section which of the both versions you want to have in the merged file. By pressing A, you take over the version you edited. By pressing B, you take over the version from the repository.