Manual
provides a graphical view of CVS.

Getting Started

Accessing The Repository
In this section we assume that you are using CVS only on the client side. That means, someone (probably the administrator of the CVS repository) gave you an account on the server machine, and it's your job to checkout modules from the repository and work with them.
CVS supports several methods of accessing the repository, which can be categorized as follows:
Local 	 The repository is something like /home/cvs/ and is simply stored in a directory which is accessible from your computer. It may physically be on a disk which is mounted via NFS, but this is an irrelevant detail. If you often use a certain local repository, you will want to tell about it.

Adding A Local Repository
Open the Repositories dialog by choosing Repository Repositories....
Press the Add... button.
Enter the details of the repository in the dialog box that displays.
Confirm by pressing the OK button.
In the future, whenever you use to check out a new module, will present you the repositories you have added here.
RSH 	 The repository name is something like :ext:bernd@cvs.cervisia.sourceforge.net:/cvsroot/cervisia.
This method requires that you have a user account on the server machine (in this case, cvs.sourceforge.net and use a remote shell for communication. By default, CVS uses rsh for this purpose, however, rsh is long considered to be insecure, and is widely replaced by ssh.
If you must use ssh, you must set the environment variable $CVS_RSH to ssh when using the CVS client. supports this easily.
Open the repositories dialog again, and press the Add... button. Now enter the name of the repository in the first line and the remote shell (⪚ ssh) in the second line. If you now confirm with the OK button, memorizes these settings.
Note that can not answer possible password requests from the server machine. You must make sure that a remote login works without requiring you to enter the password. With plain vanilla rsh, this can be achieved for example by creating a $HOME/.rhosts file with a list of trusted hosts (see the rsh manpage).
With ssh, it can be achieved by copying your public key $HOME/.ssh/identity.pub to the server. In this case, the key must not be encrypted with a passphrase (see the ssh manpage and the CVS/SSH FAQ on SourceForge). If you are unsure about these issues, ask your system administrator.
pserver 	 pserver - The repository name looks like :pserver:gehrmab@cvs.kde.org:/home/kde
This method accesses the server via a special protocol with a relatively weak authentication (pserver stands for password authentication). Before you can use such a server, you have to login. As this isn't directly supported by , enter on the command line

%cvs -d :pserver:joe@cvs.kde.org:/home/kde login

(of course, with your repository substituted). CVS will prompt you for your password and check with the server. If the password is ok, the repository name, together with the (slightly scrambled) password, will be appended to the file $HOME/.cvspass. Whenever CVS accesses the repository, it will silently send the password to the server, so you do not have to take care of that once you have logged in. As everybody who knows your password can work with the repository in your name (and even do major damage to it), you should keep the $HOME/.cvspass secret and non-readable for others.

Importing a module into the repository
In this section, we discuss how you put a new project into the CVS repository. If you just want to work with an existing project which is already in a repository, you may skip this section.

A screenshot of 's import dialog
>A screenshot of 's import dialog
In A screenshot of 's import dialog you can see the dialog which helps you to import a project as a module. After you have filled out this form and confirmed by OK, the following CVS command is used:

cvs -d repository import -m "" module vendortag releasetag

The name of the $CVS; repository, also known as $CVSROOT. You must have write access to it, and the repository must be properly initialized. If the repository does not yet exist, initialize it with the command cvs -d repository init.
If the repository is remote, make sure that authentication works (see Accessing The Repository
The name of the module under which the project will be stored. After the import, the project can be checked out under this name. See Checkout a module from the repository for more information. This is also the name of the corresponding directory in the repository.
The vendor tag is historically used for tracking third-party sources. Just use your user name if you have no better idea. It does not matter much what you enter here.
This tag is also historically used for importing different versions of third-party software. If you are not doing this, use the word start or a string FOO_1_0 where FOO is the name of your project and 1.0 is the version number of the imported release.

Working directory
This is the toplevel directory of the project you want to import. The import starts from this directory and goes down recursively.

Ignore files
If you fill out this field, an additional -I filenames option is given go the cvs import command. This entry is interpreted as a whitespace-separated list of file name patterns which are ignored. In general, a cleaner and less error-prone way to control which files go into the repository is to create a directory with only the files which you want to import and start from that. Nevertheless, this entry may be useful if the project contains files which are by default ignored by CVS, e.g. files with the name core. In such a case, simply enter the character ! in this field. This overrules CVS's scheme of ignored files, see Ignored files.

Import as binaries
If you check this box, all files are imported in binary mode, i.e. an argument -kb is given to cvs import.

Checkout a module from the repository
Before you work on a project under revision control, you must check out a working copy.

A screenshot of 's checkout dialog

Repository
The name of the CVS repository, also known as $CVSROOT. If the repository is remote, make sure that authentication works, see Accessing The Repository.

Module
The name of the module to be checked out. If you are working with an existing repository, you have probably got this name from the administrator. Alternatively, if the repository has a $CVSROOT/modules file, you can retrieve a list of available modules by clicking on the Fetch list button.

Working directory
The directory under which the module should be checked out. Note that the toplevel directory of the working copy is always created as a directory with the name as the module under the directory given here.

The main screen
When you start , and open a working copy by choosing File Open Sandbox... you see a hierarchical view of the current directory. According to the settings in your .cvsignore files, the files you usually do not want to include into the repository - like e.g. object files - are not shown. For each file, you see its corresponding status. In the default setting, this is "Unknown" because delays the fetching of information until you choose Update or Status from the File menu. With this approach, you have a minimal amount of functionality available even if you do not have a permanent connection to the CVS server.

A screenshot of 's main view
The commands in the File menu usually act only on the files which you have marked. You may also mark directories. Now choose Update from the File menu. issues a

cvs update -n
 filenames

command to get status information for the marked files. Note that goes recursively into subdirectories. only if you have the according option in the Settings menu set. According to the respective file's status, you now see an entry in the Status column:
Locally Modified - This means you have modified the file compared to the version in the repository.
Locally Added - This means the file does not exist in the repository, but in your working directory and you have scheduled it for addition. The actual insertion into the repository only happens after a commit.
Locally Removed - This means you have scheduled the file for removal, but it still exists in the repository. The actual removal happens only after a commit.
Needs Update - This is shown if a newer version of the file exists in the repository, e.g. because someone commited a modification. Normally, you want to update this file so you have an up-to-date version in your directory.
Needs Patch - This is essentially the same as before. The difference is only the hint that in case of an update, the cvs server transfers only a patch instead of the whole file to you.
Needs Merge - Indicates that a merge of the revision of this file in your working directory with the version in the repository is necessary. This typically happens if you have made modifications to the file file while someone else has commited his modifications. If you choose to update, the modifications in the repository are merged into your file. In case of a conflict (i.e. if someone else has changed some of the same lines like you) the new status is then "Conflict".
Up to Date - Indicates that the file is identical with the version in the repository.
Conflict - This is shown if this file still has conflict markers in it. Maybe you have previously updated the file and not resolved the conflicts.
Not In CVS - Indicates that the file is not registered in the CVS. If you want it to available for others, you should add it to the repository. If not, you may consider adding it to your .cvsignore file.
Now that you have got an overview of the current status of the CVS, you may want to do an update. Mark some files (or the root of the directory tree which is equivalent to marking all files in this directory). Now choose Update from the File menu. (Of course, you could have chosen this at the beginning of the session). For some of the files the status may change now. Typically, files which had "Needs Patch" or "Needs Update" are updated. So the following new items are possible in the status column:
Updated - Shown if the file was updated from the repository.
Patched - Indicates that the cvs server has sent a patch for this file and the patch has been sucessfully applied. If the patch was not successfull because there was a conflict between your modifications and those someone else commited to the repository, the status is now "Conflict".
You may have noticed that according to the status of the file, its row has a different color. The colors are chosen to somehow reflect the priority of the status. For example, a file with a conflict is marked red to show you that you have to resolve a conflict before you can continue working with the file. If your directory contains a high number of files, you may nevertheless lose the overview. To get more concise information about which files have an unusual status, simply click on the header of the Status column. The file list is then sorted by priority, so you have all important information at the top of the list. To get back to the alphabetically sorted view, click on the header of the File name column.