CVS
From Software By Jeff
Concurrent Versions System is the de facto standard for Open Source version control. Mature and widely accepted, CVS offers not only keen source control for your project, but also access to almost every Open Source project on the Internet.
CVS comes in two components within the same program, a server and a client. A server is almost necessary in the case where multiple computers will be used to access the repository. The client is necessary to access a repository, whether hosted on a server or within the computer's local file system.
| Table of contents |
Installation
The best place to get the latest release of CVS is directly from CVS Home (http://www.cvshome.org). CVS is available as a binary release for nearly every operating system including Microsoft Windows, Sun Solaris, LINUX, and Mac OSX, as well as AIX, SGI, and HP. It is also available in source form, if you prefer to build it yourself. You can download the files from the website, or quite conveniently, from their CVS repository.
Most LINUX systems come with CVS pre-installed--it is a de facto standard. Try cvs --version from a shell before downloading to see if it's even necessary to install. Configuration may be required to host a repository, but not to use the client.
Binary Installation
You can simply download the appropriate binary archive for your operating system and platform, and extract the archive. In addition to some potential README information, you'll have the CVS executable. Copy this file to somewhere on your path, like /usr/local/bin. You may need to rename the file or symlink cvs to it. You can test its installation by typing cvs --version and you should be rewarded with the correct version.
Source Installation
The source installation is much more difficult than the binary installation, but it does offer the piece of mind that something unwanted didn't get slipped in there, and ensures that any external libraries needed match your system.
Get the source from CVS Documents & files (https://ccvs.cvshome.org/servlets/ProjectDocumentList). Uncompress the file into its source. Perform the standard "configure and make" steps. Your method of retreival may be different, and you may prefer another compression over gzip. Additionally, they have GPG signatures for their files, so you can verify that the file you download is the file they present. The basic steps are as noted below.
wget https://ccvs.cvshome.org/files/documents/19/744/cvs-1.11.19.tar.gz tar -xzf cvs-1.11.19.tar.gz cd cvs-1.11.19 ./configure make make install
Of course, this requires you have the necessary tools to compile C code on your system.
Instructions would vary for Microsoft Windows source.
Repository Creation
Once installed, you can begin working with CVS immediately. Whether working with CVS using filesystem access or as a client-server configuration, you need to start with a repository.
Very simply, make a directory to hold your repository and initialize it. CVS will do this for you in one easy step. For example, I used /var/cvs initialized as a CVS repository by issuing the command:
cvs -d /var/cvs init
This will create the appropriate CVS control directories and files in the specified directory. Note the directory doesn't need to exist first, CVS will create it, but you must have permissions to creat the directory in the location chosen.
If you are going to use the pserver set-up, which we recommend even when working only with one system, this must be done on the system that will run the server, not your workstation.
Note that the repository is the storage location for your projects. You can hold many projects in one repository. You are not required to separate projects into separate repositories. You may want to, for security reasons, for example. You many have more than one repository on each system, and the only thing to be careful of is that you don't put one inside another; unwanted access may occur to "inner" repositories. The discussions that follow are related to each repository; therefore if you have more than one you will have to repeat these steps for each repository.
Server Configuration
Setting up a pserver is key to having a CVS system for multiple developers. It is not so vital to set up a separate server when working on one system. CVS has the ability to access the file system as a repository, as well as accessing a server-based repository. We recommend the pserver use, however, as it is the only way to enforce user access, and the only way that allows that access to be independent from the operating system security.
Typically this is done on UNIX-like systems, including AIX, HP, LINUX, Solaris, and Mac OSX. Running a server on Microsoft Windows is discouraged by the folks at CVS, although it can be done, and we'll show you how.
Configuration on LINUX, Mac, Solaris, etc
The primary key to getting a server-based configuration is to get the system acting as the server to listen for incoming connections. There are two widely used network service controllers, and one or both may be used; inetd and xinetd.
Additionally, it may be necessary to add or uncomment a line to the /etc/services file:
cvspserver 2401/tcp
This configures the port, normally 2401, on which the system will listen for connections from CVS clients. You may use a different port if you wish, although you need to be consistent throughout the configuration and client use. Port 2401 is the de facto standard port, so it should be used if you're going to offer your software to the worldwide communtiy.
inetd Configuration
On many LINUX distributions this information is already provided in the appropriate configuration file, but has been commented out. Simply un-comment, or enter your own line with the appropriate information.
In the /etc/inetd.conf file, look for or add a line, all together, that looks like this:
cvspserver stream tcp nowait root /usr/local/bin/cvs -f --allow-root=/var/cvs pserver cvs
This provides the network service listener the program to which it will hand connections on the configured port. The /usr/local/bin/cvs is determined by where you put cvs. The --allow-root parameter also is determined by where you wish your repository to be. More than one --allow-root parameter is allowed, separated by spaces. These directories are the only ones that CVS will allow the users access.
Now restart inetd in accordance with your system's requirements, so it can recognize the changes made, and the CVS pserver will be available.
Too Many allow-root Parameters
Some implementations of inetd have a limit on the size of the lines allowed in the inetd.conf file, and since everything must be on one line in the file, it can limit what you can do with allowing more than a small number of roots. Note that CVS does not have this limitation, so providing it a very long list is not a problem.
Instead of directly using the cvs command in the inetd.conf file, create a script that will invoke the CVS as a server with the correct parameters, and invoke the script, not cvs, in the inetd.conf.
First create a script to call cvs with your desired parameters Something like the following:
/usr/local/bin/cvsserver
#! /usr/bin/bash ALLOWROOTS="--allow-root=/var/cvs \ --allow-root=/usr/local/cvs" /usr/local/bin/cvs -f $ALLOWROOTS pserver
Then make the inetd.conf file reference that script as this example shows:
cvspserver stream tcp nowait root /usr/local/bin/cvsserver cvs
Note the call to the script is still short enough to make inetd happy. The script also provides an easy location to maintain the roots, and the maintainer does not need to have access to the inetd.conf file.
xinetd Configuration
Configuration using xinetd is similar; add a bit to the configuration file, restart the server. The configuration format is a little different, and that's about it. Following the discussion above for what the bits mean, the addition of the following lines should suffice to get the installation configured.
service cvspserver
{
port = 2401
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/local/bin/cvs
server_args = -f --allow-root=/var/cvs pserver
}This block can be added to the /etc/xinetd.conf file directly, or as some installations use, as a separate file in a directory, typically /etc/xinetd.d (which would be noted in the /etc/xinetd.conf file). This has the benefit of allowing one to maintain the cvspserver file without requiring access to the other xinetd configuration files.
Like the inetd discussion above, many roots are allowed, simply by adding them to the server_args line. Unlike inetd, xinetd does not seem to have the same length limit so the use of the script seems to be unnecessary.
Now restart xinetd with the appropriate steps for your system.
Configuration on Microsoft Windows
When using CVS as a client on Microsoft Windows, the process is no more difficult than on other platforms. A precompiled binary is available from CVS Documents & files (https://ccvs.cvshome.org/servlets/ProjectDocumentList). Download, unzip, and rename the resulting file. Put the file somewhere in your path, and you're now able to connect to CVS repositories.
Using Microsoft Windows as a repository host is only recommended with file access. Paired with Window's built-in peer-to-peer networking, mapping to the repository file location should be easy to do, and will allow version control. It does not, however, offer any of the authentication and protection of the pserver method used by the rest of the CVS servers.
The CVS (http://cvshome.org) software doesn't provide a server that operates natively on Windows. Their documentation (https://www.cvshome.org/dev/codewindow.html) points us instead to CVSNT (http://cvsnt.org).
Installation is as with any Microsoft program, run the downloaded program and click the options you desire. If you install with administrative permissions, you'll be prompted to install CVSNT as service. Do this, and you're gold.
CVS Filesystem Security
As with any other files on your system, some attention must be paid to filesystem security. In the case of CVS there are three things to note for each repository.
The repository's CVSROOT directory needs only be readable by cvs and the maintainer.
Note that while the configuration examples use the user root, it should be noted that you can use a different user to run the CVS server. This is recommended for all services, not just CVS.
Instead of allowing root to run cvs (which is not required since the port it uses is out of the root-only range), make a proxy user, which we name cvsproxy and in its own group, also named cvsproxy. Remove login access from the account (set it to the common /usr/bin/false script that promptly exits when login is attempted).
Once you've created the cvsproxy user (and presumably matching group), change your inetd or xinetd configuration to use this user. Now if malicious code is attempted to be executed via the CVS pserver connection, it will be limited to whatever you give the cvsproxy user. If done correctly, this should limit the potential damage to only CVS files.
Also, now that you have a user with which to limit access, you should limit the access. Change the owner of the CVS repository to the proxy user, with the command like chmod -R cvsproxy:cvsproxy /var/cvs, using, of course, the appropriate names for the user, group, and directory. Do this for each of your repositories.
Now that cvsproxy owns the repository directory, it should be protected from other users on the system. Generally, if you use CVS to create the directory structure, and you configure all of your CVS users as members of the cvsproxy group, or as we see, proxied to the cvsproxy user, no additional changes are required. Using CVS to control the files should automatically generate files and directories with the correct permissions.
User Configuration
If you don't want to create user accounts for everyone who may need access to your CVS repository, there's a simple technique for allowing users to have only CVS accounts. We recommend this technique even if users have account access to the system on which the server will run. It offers protection from malicious CVS use.
First, a user account must exist on the system that CVS can use instead. For example, we previously created a user named cvsproxy, and give that user next to no access on the system.
Then in the CVSROOT directory under the directory noted in the appropriate --allow-root parameter (in our case /var/cvs/CVSROOT), create a file named passwd. Also, in the same directory, edit the config file, finding the line that says SystemAuth=no and make sure it is uncommented (remove the # symbol). This now requires you to have an entry in the password file for users of CVS, and no longer allows any user on the system access by defult.
The password file, passwd, should have one line for each user in the form of user id:encrypted password:proxy where proxy is a real account id. If you wish to allow access to a user who already has an account, put their user ID in both places (or just the proxy position, if they wish a different ID for CVS), and copy their encrypted password from the /etc/passwd file. The encrypted password may be left blank, but that would mean that the user has no password, which is not recommended.
In the case of users without a regular system account, you need to make an encrypted version of the password you wish to assign. Two simple tricks exist. The easy one is to change the password of the proxy user (in my example, cvsproxy). Since that user cannot log in anyway, their password is irrelevant. Use the passwd cvsproxy command as root to set a new password for the user, then copy it from the /etc/passwd file into the CVSROOT/passwd file. You can do the same thing by creating a new user, copy the password, and then delete the user.
Optionally, while not requiring root privileges, an installation of PERL must exist, which is also the norm on LINUX and the like, this one-liner will generate an encrypted password favorable to your system.
perl -e 'print crypt "PASSWORD", "12"; print "\n"'
Substitute PASSWORD with whatever is desired, and 12 with any two characters as a random seed. This will display the encrypted password in the console, and you can enter that string in the CVSROOT/passwd file.
Now that users have access, it is important to note that without doing anything else everyone has the same access: read and write. While this may be desirable, it may be the case that you have the need to control who can read and who can write, or to allow anonymous, read-only access.
Read-only access can be accomplished by putting the user's ID in a file in the CVSROOT directory named readers. Any user listed in this file will be allowed only read access, and cannot contribute to the repository. Any one not listed in the readers file will be allowed write access.
Optionally, you can create a list for the users with write access, if that group is smaller, by making a file in the CVSROOT directory named, of course, writers. Anyone listed in this file will have write access to the repository. Anyone not listed in this file, if it exists, will have read-only access.
You can have both files, and if a user is listed in both, the safety of the repository will be considered first, and the user will be considered read-only. We recommend only listing readers, as the maintenance of writers can get cumbersome.
To allow anonymous access, then, create an anonymous user in the passwd file by putting the user ID line of anonymous::cvsproxy noting there is no password, using whatever name you wish to have, although anonymous is the standard. Then create the readers file and include anonymous in there. All other users will have write access, but anonymous users will be able to only retreive from the repository.
Let's therefore imagine we want to set up anonymous access to our repository with one real user (realuser) and one CVS only user (cvsonlyuser), using the procedures described above. Then your two files might look like this.
/var/cvs/CVSROOT/passwd
anonymous::cvsproxy cvsonlyuser:PWnf8nahwod:cvsproxy realuser:HwEInp20ngpw:realuser
/var/cvs/CVSROOT/readers
anonymous
Note that each file must end with an empty line; that is the last line should have a "new line" on it.
Quick Client Overview
This is not intended to be a thorough investigation of CVS. Our use of CVS will be limited primarily to authentication, creating projects in our repositories, retrieving files from a repository, presumably to work on, and returning them to the repository, as new versions. Much of this is integrated into our IDEs, which is discussed in more detail. However, we will be using CVS in some scripts, like our Ant build scripts, so a brief overview is warranted.
Connection and Authentication
Once the pserver is setup and configured, connecting to the repository should be the next test. There are two ways to do this, and the difference depends on how you want to note the server to which you're connecting.
The primitive use of CVS for a filesystem-based access looks like this:
cvs -d /repository command
While the primitive use of CVS for pserver-based access looks like this:
cvs -d :pserver:user@host:/repository command
Where user is the username used to authenticate the user (pserver only), host is the system name to which we're connecting (which may be localhost if we're in a one-system setup, again pserver only), and /repository is the actual path to the CVS repository (in our examples so far we've used /var/cvs). We say command although there may be more than one word there, depending on what it is you're trying to do.
Before we go on, the -d :pserver:user@host:/repository can become cumbersome to type with every CVS command. This can be shortcut by setting an environment variable named CVSROOT, allowing this to be skipped in the command, as thus:
set CVSROOT=:pserver:user@host:/repository export CVSROOT cvs command
Note that unless overridden by using a "-d" string, all subsequent CVS commands will access the same repository. This is a blessing when always working with one repository, and the set/export can even be added to your login profile if it makes sense. It can be a curse, however, when working with more than one repository, as it often causes confusion.
Note also that you can specify the password with the user ID by putting both in the "user" portion of the CVSROOT, separated by another colon, as in user:password. While there are risks of doing this (for one, your password ends up in your shell's command history), there are benefits as you are not prompted for a password. We recommend using this only when there is no password, like when using anonymous CVS access.
With this understanding, let us login now to our newly configured server, using our example setup above. Note that logging in is only necessary for pserver use, and not for local filesystem access.
cvs -d :pserver:anonymous@localhost:/var/cvs login
You will be prompted for a password, to which you would just hit enter as there isn't one for our anonymous user. CVS should respond silently unless there is an error, in which case there would be an error message.
You are authenticated with the server, and will remain so until you explicitly log out. A file is created in your home directory named .cvspass, containing the authentication key to the server that is valid for the life of the file.
You do not need to be authenticated for any period of time longer than your CVS activity. That is, you can authenticate, check out, disconnect, and work without a problem. Then you would authenticate, check in, and disconnect when finished with your bit of work.
Project Creation
Creating projects in the repository is, obviously, only necessary when making new projects. This can be done in a couple of ways; either from scratch or from an existing project structure.
Using existing Projects
From scratch is very straight forward. On your system, navigate to the directory in which you wish to work. For example, we'll go to ~/projects and consider this our local project root. In this root directory, we have a project directory for our project already started, for example, ~/projects/killerapp. Inside that directory are our source files, images, and other resources necessary for our application.
Once we've authenticated with the server, we can add our project and its files to the repository.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT cvs login cd ~/projects/killerapp cvs import -m "Creating Project" killerapp creation start
The CVS import command does the work of creating the project in the repository. It will recurse through all of the directories in your current working directory, and create all of the directories and files. It will do its best to determine text and binary files, and when completed, the repository will contain the contents of your current directory and the CVS files required to maintain the history and version control. Depending on the sise of your existing project, and the speed of your server and network connection, this may take a while.
Let's look in detail at the parameters.
The optional -m parameter, followed by a comment, will put the comment in the CVS history. Strictly, the comment is not optional, although it can be blank, and if not provided with the -m parameter CVS will pause and prompt you to enter one.
The killerapp in the import command is the project path in the CVS root that will be created. This does not need to match your directory name in any fashion, and is strictly for later use in identifying the This can be a deeper path (i.e. killerapp/source), but this is reflective of the directory created on the CVS repository, not the directory currentl working in. That is, it will create a path on the CVS repository matching this string and then insert your directories and files there. In our example, the directory /var/cvs/killerapp will be created on our server. Had we used the killerapp/source, the directory /var/cvs/killerapp/source would have been created and used.
The creation in the import command is the vendor tag. This is just a string carried with the project in CVS. It is used in the CVS reporting, and should contain something more useful. If you want to use a string with spaces, simply put the tag in quites, as we did with "Creating Project".
Likewise, the start tag in the import command is the release tag. This is also carried with the project in CVS, and used in reporting, and project milestones, and can contain something more useful.
Projects from Scratch
Creating projects from scratch is not unlike the above existing projects, except that you'll be starting in an empty directory.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT mkdir -p ~/projects/killerapp cd ~/projects/killerapp cvs login cvs import -m "Creating Project" killerapp creation start
This import will go very quickly, as there are no files to import. However, the repository exists, and while empty, it can now be used to manage your project.
Checking out
Checking out files from CVS is really pulling the files from the repository. It does not specifically mark them in CVS as files that you will edit.
Very simply call the checkout command.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT mkdir ~/workspace cd ~/workspace cvs login cvs checkout killerapp cd killerapp
This will copy everything in the /var/cvs/killerapp directory into your ~/workspace/killerapp directory, creating the entire directory structure and all files previously committed to the repository. Inside the directory will also be CVS directories. These are internal directories used by your local CVS to coordinate your local file structure with the server's structure. This helps CVS, for example, know which files you modified, so at check-in time, only those files are committed.
If this was done immediately after the project creation above, the directory structures should match, with the execption of the additional CVS directories in the ~/workspace/killerapp tree. At this point it is safe to remove or archive the ~/projects/killerapp tree as the files are stored in CVS.
You would at this point work in the ~/workspace/killerapp directory as you would have previously worked in ~/projects/killerapp, except now the files are part of the version control system, and can more effectively be shared with other developers.
Note that the checkout command has several options, allowing control over which files are retreived, which we are not going to discuss here, as this is a brief overview. See the additional resources below for detailed information.
Working on Files
Very simply, make whatever changes you find necessary. CVS, unlike some source control systems, does not restrict access to the files in your local workspace. It uses the internal CVS directories in each source directory to ascertain changes when you are ready to commit them to the repository.
Feel free to add and alter files as necessary.
Adding New Work
Through the course of work you'll find that you need to add new files and directories to the repository. In your workspace, simply create the directories and files as you find it necessary. As you create the new items, either immediately (so you don't forget) or in bulk when you're ready, simply use the add command to add the files to the queue.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT cd ~/workspace/killerapp mkdir something touch something/somefile cvs login cvs add something cvs add something/somefile
This simply queues the files and directories for addition to the repository, it does not actually add them at this point! Important to remember, also is that the command is not recursive; you must specify each file individually.
Removing and Moving files
Removing is very simple. Simply delete the file you no longer wish to have, and issue the cvs remove file in that directory, or a parent directory. This will note the change and CVS will disregard the file in future check-outs and updates, but maintain the file's versioning history.
Moving or renaming files is almost as simple. Simply copy the file to the new location and delete it from the old location (or move it). Then issue a remove command to tell CVS to forget the old file, and an add command to tell CVS about the new file.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT cd ~/workspace/killerapp cvs login mv something/somefile something/otherfile cvs remove cvs add something/otherfile
Based on the previous example, the something/somefile exists, but we want to rename it something/other file. The remove command is recursive, so it will see the somefile is missing from the something directory, and make note of your intention to delete it. The add is not, so we must explicitly tell it which file we're adding.
Refreshing Work
CVS does not automatically synchronize the repository's contents to your system. You must tell CVS when you want to refresh your directory structure. This is done with the update command. It is also recursive, and will update from where you are in the directory structure, and not from the top. It is recommended, therefore, to do the update from the root of your project.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT cd ~/workspace/killerapp cvs login cvs update -d -P
By default, update is fairly gentle on your system. It removes files that have been marked as deleted in the repsository, adds new files from the repository, and updates existing and modified files. All of this work is only done in the directories previously existing. We need to use the -d and -P to ensure that directory changes are included in our update.
The -d parameter adds new directories from the repository, and the files within them, recursing as necessary.
The -P parameter removes any directories that have been deleted from the repository. More correctly, it removes empty directories, which is how CVS determines they've been deleted.
At the completion of the update, your local structure should look like the repository, plus your changes. It's a good practice to do an update before you attempt to commit. This will help you avoid conflicts and keep missing work from other developers at a minimum.
Conflict Handling
As much as possible, CVS update will try to merge any changes made in files that you have modified that have also been modified in the repository since your last update. It does this by fairly robust, albiet not perfect, comparison. It may be the case that the resulting merge is not easy enough for CVS to do. Typically this is reserved for changes CVS perceives in the same location of a file. Merge also does not work on binary files. In this case CVS may complain and you'll have to do this merge manually. Inside the IDEs, this is more easily performed.
Another thing to keep in mind, is that while the update merge may not find any conflicts, it might introduce merges that do not make computational sense. It is important, therefore, to review files that have merges in them, even if the merge did not report any errors or conflicts.
Outside an IDE, however, we must do the merge manually. When CVS merges the file, it will mark conflicts with <<<<< and >>>>> markers to note what lines were in the repository and what lines are in your file. Left alone, these should cause compiler errors, at the least, helping you find the files that have merge errors. You can edit the lines as you see fit. Since the update is done, CVS will assume any change you make is to the version last committed to the repository.
If you want to check before you update, to see what merge issues may result, CVS provides a tool for determining the differences in a file, as a method for you to find and correct doverlapping work.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT cd ~/workspace/killerapp cvs login cvs diff -w something/somefile
The -w tells CVS to ignore whitespace, to help reduce space-vs-tab conflicts and other formatting style changes.
Note that the diff command is not recursive, so you must provide the file that you wish to compare.
The command will display the lines were added or deleted or changed in either or both files. You then have to edit your local copy to either match or otherwise affect it to be correct.
File Locking
One alternative, that really removes the "C" from CVS, is to lock files instead of opening the system. In this case, a file can only be edited by one developer at a time. This is enforced by making the files read-only when checked out, and forcing developers to mark individual files as they modify them.
First the repository needs to be so marked using the CVS watch command.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT cd ~/workspace/killerapp cvs login cvs watch on
The watch command is recursive, so you should do this from the root of the project. You also only need to do it once, not whenever you access the repository. It is also possible to use watch on only specific files, for example, files that don't merge well like binaries or configuration files.
Then to edit the file, simply issue the CVS edit command on the file. This will check to see if the file is available, and if so, let you edit the file. The file will remain locked as yours until you commit the file, at which time your lock will be freed.
cvs edit something/somefile
If someone else has a file locked, you will be alerted, and
If you decide you don't need to edit the file, you can undo the checkout with an unedit command. This will revert your local copy of the file to what is in the repository, and release your lock on the file, allowing other developers access.
cvs unedit something/somefile
Checking in
When you're ready you can commit your work to the repository. This can be done on individual files, for example as you create new directories, or on the whole project structure. CVS keeps track of the proper repository structure, so you don't even need to worry about which directory you're in, as long as you're somewhere within the project. Well, OK, if you have changes within different directories, it is important to remember that CVS only works from your current directory and deeper into the structure; it will not recurse to the top of your project and commit for you.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT cd ~/workspace/killerapp cvs login cvs commit -m "Relevant Message"
This will recurse through our directory structure finding files we've changed and add, remove, or update them as appropriate based on previous cvs commands and file modifications.
The commit command, like the import, requires a message to add to the check-in. The message may be blank (""), but that is discouraged. If you do not provide a -m parameter, you'll be provided with an editor in which to enter your comments.
When to check-in is a topic of much debate. In iterative, test-driven development, it should be often, but after a successful compile and run of your code. It is certainly noteworthy that no one else can see your additions and changes until you commit your changes.
Disconnecting
When you're done using the repository, simply disconnect by logging out.
set CVSROOT=:pserver:cvsonlyuser@localhost:/var/cvs export CVSROOT cvs logout
This will remove the information related to this repository from the .cvspass file in your home directory. Future CVS interactions will result in authentication errors until you reconnect and login.
Note that you can span tremendous periods of times between logins and logouts. It has nothing to do with your network session or even the lifespan of the CVS server. The entry made in the .cvspass file simply does the authentication key for you each time CVS commands are issued.
IDE Integration
CVS is integrated in most of the popular IDEs available. It is integrated into both Eclipse and NetBeans, which we whole heartedly recommend for both Java and C/C++ development. The application of the process is similar for each, and discussed in detail in the corresponding Eclipse and NetBeans sections.
Worldwide Use
As mentioned, CVS is the Open Source de facto standard. All of our favorite Open Source repositories use anonymous CVS, allowing us to keep our local copies of their source up-to-date with their releases.
Apache Foundation (http://apache.org) has direct access to their sources (CVSROOT=:pserver:anoncvs:@cvs.apache.org:/home/cvspublic). This is important as many Java tools we will be using come from Apache.
The collections at SourceForge (http://sf.net), and FreshMeat (http://freshmeat.net) both have CVS access to download the sources of the projects that they host or participate in.
Even the source for the IDEs Eclipse (CVSROOT=:pserver:anonymous:@dev.eclipse.org:/home/eclipse) and NetBeans (CVSROOT=:pserver:anoncvs:@cvs.netbeans.org:/cvs) are available via CVS.
Other source, not being discussed here is available, too, like Mozilla's browsers and other clients (CVSROOT=:pserver:anonymous:@cvs-mirror.mozilla.org:/cvsroot).
Additional Resources
CVS on-line manual (https://www.cvshome.org/docs/manual)
CVS "cederqvist" documentation (https://ccvs.cvshome.org/servlets/ProjectDocumentList)