1. Overview

This chapter is for people who have never used CVS, and perhaps have never used version control software before.

If you are already familiar with CVS and are just trying to learn a particular feature or remember a certain command, you can probably skip everything here.

1.1 What is CVS?

CVS is a version control system. Using it, you can record the history of your source files.

For example, bugs sometimes creep in when software is modified, and you might not detect the bug until a long time after you make the modification. With CVS, you can easily retrieve old versions to see exactly which change caused the bug. This can sometimes be a big help.

You could of course save every version of every file you have ever created. This would however waste an enormous amount of disk space. CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions.

CVS also helps you if you are part of a group of people working on the same project. It is all too easy to overwrite each others’ changes unless you are extremely careful. Some editors, like GNU Emacs, try to make sure that two people never modify the same file at the same time. Unfortunately, if someone is using another editor, that safeguard will not work. CVS solves this problem by insulating the different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done.

CVS started out as a bunch of shell scripts written by Dick Grune, posted to the newsgroup comp.sources.unix in the volume 6 release of July, 1986. While no actual code from these shell scripts is present in the current version of CVS much of the CVS conflict resolution algorithms come from them.

In April, 1989, Brian Berliner designed and coded CVS. Jeff Polk later helped Brian with the design of the CVS module and vendor branch support.

You can get CVS in a variety of ways, including free download from the Internet. For more information on downloading CVS and other CVS topics, see:

http://cvs.nongnu.org/

There is a mailing list, known as info-cvs@nongnu.org, devoted to CVS. To subscribe or unsubscribe write to info-cvs-request@nongnu.org. If you prefer a Usenet group, there is a one-way mirror (posts to the email list are usually sent to the news group, but not visa versa) of info-cvs@nongnu.org at news:gnu.cvs.help. The right ail list areuthentication).

Unlike with previous versions of CVS, read-only users should be able merely to read the repository, and not to execute programs on the server or otherwise gain unexpected levels of access. Or to be more accurate, the known holes have been plugged. Because this feature is new and has not received a comprehensive security audit, you should use whatever level of caution seems warranted given your attitude concerning security.

There are two ways to specify read-only access for a user: by inclusion, and by exclusion.

"Inclusion" means listing that user specifically in the ‘$CVSROOT/CVSROOT/readers’ file, which is simply a newline-separated list of users. Here is a sample ‘readers’ file:

melissa
splotnik
jrandom

(Don’t forget the newline after the last user.)

"Exclusion" means explicitly listing everyone who has write access—if the file

$CVSROOT/CVSROOT/writers

exists, then only those users listed in it have write access, and everyone else has read-only access (of course, even the read-only users still need to be listed in the CVS ‘passwd’ file). The ‘writers’ file has the same format as the ‘readers’ file.

Note: if your CVS ‘passwd’ file maps cvs users onto system users (see section Setting up the server for password authentication), make sure you deny or grant read-only access using the cvs usernames, not the system usernames. That is, the ‘readers’ and ‘writers’ files contain cvs usernames, which may or may not be the same as system usernames.

Here is a complete description of the server’s behavior in deciding whether to grant read-only or read-write access:

If ‘readers’ exists, and this user is listed in it, then she gets read-only access. Or if ‘writers’ exists, and this user is NOT listed in it, then she also gets read-only access (this is true even if ‘readers’ exists but she is not listed there). Otherwise, she gets full read-write access.

Of course there is a conflict if the user is listed in both files. This is resolved in the more conservative way, it being better to protect the repository too much than too little: such a user gets read-only access.

2.11 Temporary directories for the server

While running, the CVS server creates temporary directories. They are named

cvs-servpid

where pid is the process identification number of the server. They are located in the directory specified by the ‘-T’ global option (see section Global options), the TMPDIR environment variable (see section All environment variables which affect CVS), or, failing that, ‘/tmp’.

In most cases the server will remove the temporary directory when it is done, whether it finishes normally or abnormally. However, there are a few cases in which the server does not or cannot remove the temporary directory, for example:

• If the server aborts due to an internal server error, it may preserve the directory to aid in debugging
• If the server is killed in a way that it has no way of cleaning up (most notably, ‘kill -KILL’ on unix).
• If the system shuts down without an orderly shutdown, which tells the server to clean up.

In cases such as this, you will need to manually remove the ‘cvs-servpid’ directories. As long as there is no server running with process identification number pid, it is safe to do so.

This document was generated by Build Daemon on February 9, 2012 using texi2html 1.82.

1. Overview

This chapter is for people who have never used CVS, and perhaps have never used version control software before.

If you are already familiar with CVS and are just trying to learn a particular feature or remember a certain command, you can probably skip everything here.

1.1 What is CVS?

CVS is a version control system. Using it, you can record the history of your source files.

For example, bugs sometimes creep in when software is modified, and you might not detect the bug until a long time after you make the modification. With CVS, you can easily retrieve old versions to see exactly which change caused the bug. This can sometimes be a big help.

You could of course save every version of every file you have ever created. This would however waste an enormous amount of disk space. CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions.

CVS also helps you if you are part of a group of people working on the same project. It is all too easy to overwrite each others’ changes unless you are extremely careful. Some editors, like GNU Emacs, try to make sure that two people never modify the same file at the same time. Unfortunately, if someone is using another editor, that safeguard will not work. CVS solves this problem by insulating the different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done.

CVS started out as a bunch of shell scripts written by Dick Grune, posted to the newsgroup comp.sources.unix in the volume 6 release of July, 1986. While no actual code from these shell scripts is present in the current version of CVS much of the CVS conflict resolution algorithms come from them.

In April, 1989, Brian Berliner designed and coded CVS. Jeff Polk later helped Brian with the design of the CVS module and vendor branch support.

You can get CVS in a variety of ways, including free download from the Internet. For more information on downloading CVS and other CVS topics, see:

http://cvs.nongnu.org/

There is a mailing list, known as info-cvs@nongnu.org, devoted to CVS. To subscribe or unsubscribe write to info-cvs-request@nongnu.org. If you prefer a Usenet group, there is a one-way mirror (posts to the email list are usually sent to the news group, but not visa versa) of info-cvs@nongnu.org at news:gnu.cvs.help. The right ail list areuthentication).

Unlike with previous versions of CVS, read-only users should be able merely to read the repository, and not to execute programs on the server or otherwise gain unexpected levels of access. Or to be more accurate, the known holes have been plugged. Because this feature is new and has not received a comprehensive security audit, you should use whatever level of caution seems warranted given your attitude concerning security.

There are two ways to specify read-only access for a user: by inclusion, and by exclusion.

"Inclusion" means listing that user specifically in the ‘$CVSROOT/CVSROOT/readers’ file, which is simply a newline-separated list of users. Here is a sample ‘readers’ file:

melissa
splotnik
jrandom

(Don’t forget the newline after the last user.)

"Exclusion" means explicitly listing everyone who has write access—if the file

$CVSROOT/CVSROOT/writers

exists, then only those users listed in it have write access, and everyone else has read-only access (of course, even the read-only users still need to be listed in the CVS ‘passwd’ file). The ‘writers’ file has the same format as the ‘readers’ file.

Note: if your CVS ‘passwd’ file maps cvs users onto system users (see section Setting up the server for password authentication), make sure you deny or grant read-only access using the cvs usernames, not the system usernames. That is, the ‘readers’ and ‘writers’ files contain cvs usernames, which may or may not be the same as system usernames.

Here is a complete description of the server’s behavior in deciding whether to grant read-only or read-write access:

If ‘readers’ exists, and this user is listed in it, then she gets read-only access. Or if ‘writers’ exists, and this user is NOT listed in it, then she also gets read-only access (this is true even if ‘readers’ exists but she is not listed there). Otherwise, she gets full read-write access.

Of course there is a conflict if the user is listed in both files. This is resolved in the more conservative way, it being better to protect the repository too much than too little: such a user gets read-only access.

2.11 Temporary directories for the server

While running, the CVS server creates temporary directories. They are named

cvs-servpid

where pid is the process identification number of the server. They are located in the directory specified by the ‘-T’ global option (see section Global options), the TMPDIR environment variable (see section All environment variables which affect CVS), or, failing that, ‘/tmp’.

In most cases the server will remove the temporary directory when it is done, whether it finishes normally or abnormally. However, there are a few cases in which the server does not or cannot remove the temporary directory, for example:

• If the server aborts due to an internal server error, it may preserve the directory to aid in debugging
• If the server is killed in a way that it has no way of cleaning up (most notably, ‘kill -KILL’ on unix).
• If the system shuts down without an orderly shutdown, which tells the server to clean up.

In cases such as this, you will need to manually remove the ‘cvs-servpid’ directories. As long as there is no server running with process identification number pid, it is safe to do so.

This document was generated by Build Daemon on February 9, 2012 using texi2html 1.82.