1. Window->Show View->Other. Select CVS->CVS Repositories.
2. Context Menu->New->Repository Location...
3. Fill in the location information identifying your repository and click Finish.
4. Expand the newly-created repository location.
5. Expand HEAD.
6. Find the module you are interested in.
7. Context Menu->Check Out As Project.

1. Select the project in the Navigator or other view.
2. Context Menu->Team->Share Project...
3. Fill in the location information identifying your repository and click Finish.
4. The Synchronize view opens, showing all your outgoing changes.
5. Select the project in the Synchronize view.
6. Context Menu->Commit.
7. Answer yes when prompted to add new files to version control.
8. Supply a release comment if you like.

1. Create a project in the workspace.
2. File->Import, select File System, locate your files, click Finish.
3. Select the project in the Navigator or other view.
4. Context Menu->Team->Share Project...
5. The wizard should tell you that it found all the necessary information. Click Finish.

When you are browsing in the CVS Repositories view, you may expect to see branch and version tags which you have previously created. In CVS, such tags are stored on individual files rather than on projects or folders. Rather than scan every file in the repository, Eclipse only scans one well-known file, .project, which should exist in every Eclipse project. It is possible that you have other interesting tags that do not appear on .project but which you would like to show up in the CVS Repositories view.

To make these tags appear, do the following:

1. Open the CVS Repositories view.
2. Expand HEAD and select the project for which you want to configure tags.
3. Context Menu->Configure Branches and Versions...
4. In the "Browse files for tags" table, select one or more files that contain tags you would like to see.
5. Click "Add Selected Tags".
6. Click "OK".

Some modules are not expandable because their definition is complex and difficult to parse on the client. These modules can still be checked out properly using the "Check Out Module" menu command from the module's context menu.

Eclipse supports CVS version 1.11.1p1 or higher, running on a Linux or UNIX server. Eclipse does not officially support running CVSNT on a Windows server, but varied degrees of success have been achieved. In this case, CVSNT version 1.11.1.1 or higher must be used.

The reason CVSNT isn't supported is because traditionally its development effort has been smaller and has lagged behind that of CVS Linux, thus its quality tends to be of issue. Our experience is that every new version of CVSNT has subtle bugs which are specific to it, while as CVS Linux has been comparatively and consistently solid. We fix CVSNT bugs where time permits but we don't include it in our test passes for reasons above. In general those who are 'serious' about it choose CVS Linux for reliability (eg. eclipse.org), which at that scale (e.g. corporate code storage) warrants a dedicated machine anyway with an appropriately chosen OS. If the community feels that a greater CVSNT effort is warranted, then this would be an excellent avenue for community contribution.

CVS for UNIX can be downloaded from http://www.cvshome.org. CVSNT can be downloaded from http://www.cvsnt.org.

The CVS manual can be browsed online at http://www.cvshome.org/docs/manual/. The CVS FAQ-O-Matic can be found at http://ccvs.cvshome.org/fom/fom.cgi.

We have reports that CVSNT 1.11.1.1 (and perhaps later versions) will not run on Windows 2000 unless Service Pack 2 or later is installed.

You have set up relative mapping (repository prefix) under CVSNT, so that, for example, "D:\cvs\repo" maps to "/REPO". That means you should be able to use ":pserver:user@host:/REPO". However, CVSNT does not always communicate these paths to the client properly; in particular, Eclipse needs information for synchronization which is not included in this mode of operation. The solution is to change your CVSNT server settings to disable the use of a repository prefix, and use the full path of the repository, thus: ":pserver:user@host:D:\cvs\repo".

This error indicates that your server version is CVS 1.10 or before. The -C option was introduced in version 1.11. See above for supported CVS versions.

This error indicates that your server version is CVS 1.11 which has a bug when replacing a locally dirty file. See above for supported CVS versions.

Eclipse sometime performs multiple commands within a single connection to the server. This may cause problems with CVS server that are running server scripts in reponse to certain commands.

Eclipse does not support the use of the local connection method as this requires a CVS client that also includes the CVS server code in it. Command line cvs uses the same executable for the client and the server whereas Eclipse is a client only. Since the repository is on the same machine as the client, you should be able to use pserver.

This error, or an error stating that "An error has occurred processing file <repo file> <revision>", occur when the CVSNT server has been configured to use a repository prefix (also referred to as a repository alias). CVSNT provides this mechanism to allow compatibility with the Unix/Linux based command line tools. However, the CVSNT server does not properly map the repository paths that are communicated in text messages. The Eclipse CVS client relies on these text messages to provide advanced features such as synchronization and compare. In order for these features to work properly, the CVSNT server must not be configured to use a repository prefix. Instead, the full path name (i.e. D:\cvs\root) must be used (see related question above).

The pserver protocol sends passwords over the network in plaintext. Many people prefer to establish a secure connection using SSH. Eclipse supports two methods of connecting to CVS repositories using SSH.

To use the Eclipse's built-in SSH support, simply specify "extssh" as the connection method type when creating the repository connection.

To use SSH support from an external tool, you must:

1. Specify "ext" as the connection method type when creating the repository connection.
2. Window->Preferences->Team->CVS->Ext Connection Method. On this page, specify the name and location of your external ssh client. (For example, "C:\plink.exe" or "/usr/local/bin/ssh"). Also specify the name and location of the CVS binary on the server. The default value is often correct.
3. Ensure that you can log on to the server using the external SSH tool without specifying a password.

The extssh connection method uses a built-in SSH client. The ext connection method allows you to specify an external SSH client to use. For extssh to work, the server must be running an SSH server with SSH1 protocol compatibility. If extssh does not work, it is likely that the server is running only the SSH2 protocol. If this is the case, you must configure the ext connection method with an external SSH client.

The steps for setting up public-key authentication vary depending on your SSH client. However, they all follow this set of common steps:

1. Use the client program (or a utility that came with it) to generate a public/private key pair. This program might be called ssh-keygen or puttygen.exe.
2. Copy the public key to the server. This is often done by pasting the public key into the file /home/user/.ssh/authorized_keys.

This often happens when using SourceForge projects for the first time, but may occur on other servers as well. You must manually log in to the server, using an interactive SSH session, in order to create your home directory for the first time. After this, you will be able to log in successfully.

Use your SSH client to connect to the server (e.g. cvs.sourceforge.net) and log in with your username and password. Your home directory will be created for you.

IMPORTANT: Before upgrading from Eclipse 1.0 to 2.0, make sure you release all your changes to the repository using Eclipse 1.0. Although it is possible to submit the changes using Eclipse 2.0 after you upgrade, to do so is not straight forward due to a change in how the synchronization information for each project is stored.

Team support changed drastically between Eclipse 1.0 and 2.0. As such, the method of sharing projects with the repository changed as well. We have tried to make it relatively easy for you to migrate, however. You will notice that your previously shared projects only have "Share Project" in the Team menu. If you select that option, a wizard will guide you through the migration process. When you are finished, your project will be shared and the Synchronize view will open. You will see conflicting changes on every file - this is due to changes in the way sync information is stored between 1.0 and 2.0. If you do not have any outgoing changes (which you shouldn't have if you committed all your outgoing changes before upgrading as recommended above), then you can simply select the project in the Synchronize view and select "Override and Update" which will load the current contents from the server. If you do have outgoing changes, you can pull down the triangle menu in the Synchronize view and select "Compare File Contents". After some work, the Synchronize view will show you only the files which are actually different. You can then use the Synchronize view to resolve these conflicts.

Any file checked into a CVS repository from Eclipse 1.0 was marked as binary. This means that end-of-line conversions will not occur on checkout, and some features of CVS (such as auto-mergeable conflicts) will not apply to these files. As such, it may be desirable to change some of these files from binary to text. To change the file types, do the following:

1. Make sure that all members of your team have saved and committed any changes to the affected files.
2. Select the resources you wish to change in the Navigator or other view.
3. Context Menu->Team->Set Keyword Substitution...
4. Select "Automatic" to use the recommended detection. Click Next.
5. Select the checkbox labelled "Include files that are already in the repository". Click Next.
6. Click Finish. All affected files will immediately be modified in the repository.
7. All other team members must now check out fresh copies of all affected files.

In an effort to move away from generic terminology that applies to all repository providers, and toward provider-specific terminologies and workflows, many terms, menu items and labels have changed in 2.0. Here is a brief list of some of the changes. For more detailed information, please see the Eclise CVS documentation.

In Eclipse 1.0, meta-information about a project was stored in .vcm_meta. In Eclipse 2.0, this mechanism was made more general and the data was moved to the .project file. As such, the .vcm_meta file is now unneeded. The Eclipse CVS client will warn you of this state by placing a warning in the task list. If you still have people on your team who are using Eclipse 1.0 for development with your repository, then you should not delete the .vcm_meta file. If all members of your team are using Eclipse 2.0, then you can safely delete the .vcm_meta file and commit the deletion to the repository.

Eclipse makes use of information in the .project file to determine if a project is a Java project. If the project you have checked out does not have a .project file, Eclipse will not mark it properly. If you use "Checkout As..." instead of "Checkout As Project" in the Repositories view, then you will be given an opportunity to specify Java as the project type and provide Java specific configuration information.

Eclipse's Java development tools create and maintain a special file, .classpath, in the root of each Java project. This file contains information about the project's classpath, including references to other projects, external jars, and the project's own source path. If you are working on a team with other developers that use Eclipse, you probably want to commit this file to the repository so that others can benefit from correct classpath settings. If the other developers on your team do not use Eclipse, you may still want to commit the .classpath file so that your settings are persisted - this should not affect the users that are not using Eclipse.

If the name of the CVS module is part of the package name of Java files, you will encounter problems. For example, if the module you check out is called "test", and it contains a folder called "code" which contains Java files that claim to be in the package "test.code", Eclipse will not be able to compile these Java classes. The solution is to move the top-level package folder ("test" in this case) to be a subfolder of the CVS module. In this case, create a folder called "test" in the project "test", and move "code" into it. Then commit your changes.

Another possible solution is to use modules definitions. Modules can be defined in the CVSROOT/modules file to include root level projects as subfolders of the checked out folder stucture. See the CVS documentation for more information on defining modules.

Source folders must always begin beneath the project, not above it. See the Eclipse Java Development Tools documentation for more information on source folders.

To check out a module that is defined in the CVSROOT/modules file as a Java project, you may have to pre-create the target project as a java project in the workspace before performing the "Check Out Module".

JDT marks most of its build output as being derived resources so that CVS and other repository types can easily ignore these resources from version control. However, if you define custom source and build output folders, the newly created build output folder will not be marked as derived. In many cases the root build output folder is named bin. To ignore this folder, select it in the navigator and choose Team > Add to .cvsignore, then commit the .cvsignore file to the repository so that the bin folder will be ignored at all times for that project.

Substitute the usual keyword (e.g. $Revision: 1.17 $) with the $ escaped version (e.g. $$Revision: 1.17 $$).

No. Eclipse implements a CVS client in Java that talks directly to the server using the documented CVS protocol. No external CVS client is required.

Eclipse stores CVS sync information in CVS/ folders in the same way as the command-line CVS client does. However, you rarely see these folders within Eclipse. They are marked using a Core facility called "team-private" which causes them to be hidden from view. If you open a (non-Eclipse) file explorer you will see that these directories and their contents appear on the file system.

Eclipse Team CVS stores its meta information in a format that is compatible with the command-line CVS client. Thus you should be able to use a CVS command line client against Eclipse workspace files on disk. Please note that this support is experimental, and you may run into problems. However, we are very interested in making this work, so please report any bugs you find.

Whenever you use external tools to modify workspace files, you must perform a Refresh from within Eclipse to make the workspace aware of the changes.

You may encounter unexpected behaviour when using the command-line CVS client in conjunction with deleted folders. Eclipse's CVS support keeps track of deleted folders and their contents so that, on the next synchronization, the Synchronize view can properly report on the changes. This information is kept outside of the CVS meta folder structure. This is because in CVS you normally inform the repository of deletions prior to deleting them locally, which is a different workflow than we like to support in the Synchronization view. Thus it is recommended that you do not use the command-line CVS client while you have pending deletions to commit. In some circumstances it could cause the Synchronize view to display incorrect contents, although it should not cause any lost work.

Yes you can. However, you may encounter errors from the builder related to the copying of the CVS folders. This can have two causes. The first is when the project is imported before the CVS plugin is loaded. To avoid this problem, make sure you open one of the CVS views before importing the project. The second is due to a "race" on import between the CVS plugin and other plugins that react to the import. If the CVS plugin wins the race, then the CS folders are hidden but if another plugin discovers the CVS folders first, it may cause the workbench to "know" about them and perform inappropriate actions on them. The only known possible cure to this problem is to shutdown and restart Eclipse. If this fails, you may need to check the projects out from your repsitory using Eclipse instead of the command line client.

This problem is caused by the keyword substitution mode assigned to the file on the server. Any binary files must be marked as -kb. The default for CVS is to mark unknown file types as text. CVS provides cvswrappers and the cvs admin command to set file types.

If you have modified a project that you checked out from CVS, you may want to send those changes to someone else. This often occurs when you do not have commit rights, but want to send the changes to someone who does. To create a patch file:

1. Select the changed project in the Navigator or other view.
2. Context Menu->Team->Create Patch...
3. Select a location for the patch.
4. Use E-mail or other delivery method to send the patch to someone else.

To apply a patch, such as one generated in the previous step, do the following:

1. Select the changed project in the Navigator or other view.
2. Context Menu->Compare With->Patch...
3. Fill in the location of the patch file
4. Click Next. A summary of changed files will appear.
5. Click Finish. The changes are now merged into the workspace.
6. Context Menu->Team->Synchronize. You may now commit the changes into the repository.

The .project file is created and maintained by Eclipse. It stores meta-information about the project, such as which projects it references and what type of project it is. If other members of your team will be using Eclipse to check out this project from CVS, you almost certainly want to release the .project file to CVS. Even if other members of your team are not using Eclipse, you may still want to release the .project file so that the information is persisted for you.

In some circumstances, depending on permissions on the server, you may not be able to browse the repository in the CVS Repositories view. In this case, it may still be possible to check out the project you want.

1. Create an empty project.
2. Context Menu->Team->Share Project...
3. Enter the repository information and click Finish
4. The Synchronize view appears. Update all incoming changes.

The project in your workspace is now shared with the CVS repository, and contains the remote contents.

There is a bug in the CVS server related to some compression levels. If you get this error, change the compression level on the CVS preferences page and see if that helps.

There is a bug in the CVS client in Eclipse 2.0 that will not purge the CVS folders properly if a folder under CVS control is moved into a folder that is not under CVS control. If this occurs, you will need to delete the CVS folders manually.

Problems have been reported in this area using IBM JRE 1.3.0 on Linux. The solution is to upgrade your JRE to version 1.3.1.

Instances of this have been reported that involve the NDIS.sys driver and particular brands of network cards (see bug 21276).