Pick an empty directory to be your CVSROOT and set the `CVSROOT' environment variable to point there. The CVSROOT environment points to where the repository lives:

export CVSROOT=/export/cvs

Create the repository directory (with the project folder):

mkdir -p $CVSROOT/CVSROOT
chown tomcat4:cvs -R $CVSROOT
chmod ug+rwx,o-rwx -R $CVSROOT
chown :cvs -R $CVSROOT/CVSROOT
ls -ld $CVSROOT

Tell CVS to initialize the repository:

cvs init
echo "*.class *.txt *.jar" > $CVSROOT/CVSROOT/cvsignore
chown tomcat4:cvs !$
chmod 644 !$

chown :cvs -R $CVSROOT

When you begin using CVS, you will probably already have several projects that can be put under CVS control. In these cases the easiest way is to use the `import' command.

export CVSROOT=/export/cvs
export CVSREAD=yes

cd /java/expresso/webapps

codesrc=expresso/WEB-INF/classes/com/
(cd $codesrc; cvs import -m "Imported sources" $codesrc gsc start)

codesrc=expresso/WEB-INF/config
codesrc=expresso/WEB-INF/tld
codesrc=expresso/expresso/jsp
codesrc=expresso/expresso/style
codesrc=expresso/foo

Unless you supply a log message with the `-m' flag, CVS starts an editor and prompts for a message. The string `gsc' is a "vendor tag", and `start' is a "release tag". They may fill no purpose in this context, but since CVS requires them they must be present.

Use `-I name' to specify file names that should be ignored during import. Or, export CVSIGNORE="*.class *.txt *.jar"

You MUST change directory to the source-code-directory and then do cvs import. Otherwise, when doing checkout it says module is unknown.

*References*: cvs.ps

When you begin using cvs, you will probably already have several projects that can be put under cvs control. In these cases the easiest way is to use the import com- mand. An example is probably the easiest way to explain how to use it. If the files you want to install in cvs reside in `wdir', and you want them to appear in the repository as `$CVSROOT/yoyodyne/rdir', you can do this:

$ cd wdir
$ cvs import -m "Imported sources" yoyodyne/rdir yoyo start

Unless you supply a log message with the `-m' flag, cvs starts an editor and prompts for a message. The string `yoyo' is a vendor tag, and `start' is a release tag. They may fill no purpose in this context, but since cvs requires them they must be present. See Chapter 13 [Tracking sources], page 79, for more information about them.

You can now verify that it worked, and remove your original source directory.

$ cd ..
$ cvs checkout yoyodyne/rdir # Explanation below
$ diff -r wdir yoyodyne/rdir
$ rm -r wdir

Erasing the original sources is a good idea, to make sure that you do not accidentally edit them in wdir, bypassing cvs. Of course, it would be wise to make sure that you have a backup of the sources before you remove them.

The checkout command can either take a module name as argument (as it has done in all previous examples) or a path name relative to $CVSROOT, as it did in the example above. It is a good idea to check that the permissions cvs sets on the directories inside $CVSROOT are reasonable, and that they belong to the proper groups. See Section 2.2.2 [File permis- sions], page 9.

If some of the files you want to import are binary, you may want to use the wrappers features to specify which files are binary and which are not. See Section C.2 [Wrappers], page 132.

The next step is to define the module in the `modules' file. This is not strictly necessary, but modules can be convenient in grouping together related files and directories. In simple cases these steps are suffcient to define a module.

It is possible to grant read-only repository access to people using the password- authenticated server (see Section 2.9.3 [Password authenticated], page 21). (The other access methods do not have explicit support for read-only users because those methods all assume login access to the repository machine anyway, and therefore the user can do whatever local file permissions allow her to do.)

A user who has read-only access can do only those cvs operations which do not modify the repository, except for certain \administrative" files (such as lock files and the history file). It may be desirable to use this feature in conjunction with user-aliasing (see Section 2.9.3.1 [Password authentication server], page 21).

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 2.9.3.1 [Password authentication server], page 21), 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.