Initiate the CVS

Decide where the main repository will rest and create a root cvs. For example /usr/local/cvs (as

root):

# mkdir -p /usr/local/cvs

# setenv CVSROOT /usr/local/cvs # Set CVSROOT to the new location (local)

# cvs init # Creates all internal CVS config files

# cvs checkout CVSROOT # Checkout the config files to modify them

# cd CVSROOT

edit config ( fine as it is)

# cvs commit config

cat >> writers # Create a writers file (optionally also readers)

colin

^D # Use [Control][D] to quit the edit

# cvs add writers # Add the file writers into the repository

# cvs edit checkoutlist

# cat >> checkoutlist

writers

^D # Use [Control][D] to quit the edit

# cvs commit # Commit all the configuration changes

Add a readers file if you want to differentiate read and write permissions Note: Do not (ever) edit files directly into the main cvs, but rather checkout the file, modify it and check it in. We did this with the file writers to define the write access.

There are three popular ways to access the CVS at this point. The first two don't need any

further configuration. See the examples on CVSROOT below for how to use them:

• Direct local access to the file system. The user(s) need sufficient file permission to

access the CS directly and there is no further authentication in addition to the OS login.

However this is only useful if the repository is local.

• Remote access with ssh with the ext protocol. Any use with an ssh shell account and

read/write permissions on the CVS server can access the CVS directly with ext over ssh

without any additional tunnel. There is no server process running on the CVS for this to

work. The ssh login does the authentication.

• Remote access with pserver. This is the preferred use for larger user base as the users

are authenticated by the CVS pserver with a dedicated password database, there is

therefore no need for local users accounts. This setup is explained below.

Network setup with inetd

The CVS can be run locally only if a network access is not needed. For a remote access, the

daemon inetd can start the pserver with the following line in /etc/inetd.conf (/etc/xinetd.d/cvs

on SuSE):

cvspserver stream tcp nowait cvs /usr/bin/cvs cvs \

--allow-root=/usr/local/cvs pserver

It is a good idea to block the cvs port from the Internet with the firewall and use an ssh tunnel

to access the repository remotely.

Separate authentication

It is possible to have cvs users which are not part of the OS (no local users). This is actually probably wanted too from the security point of view. Simply add a file named passwd (in the CVSROOT directory) containing the users login and password in the crypt format. This is can be done with the apache htpasswd tool.

Note: This passwd file is the only file which has to be edited directly in the CVSROOT directory.

Also it won't be checked out. More info with htpasswd --help

# htpasswd -cb passwd user1 password1 # -c creates the file

# htpasswd -b passwd user2 password2

Now add :cvs at the end of each line to tell the cvs server to change the user to cvs (or

whatever your cvs server is running under). It looks like this:

# cat passwd

user1:xsFjhU22u8Fuo:cvs

Test the login as normal user (for example here me)

# cvs -d :pserver:colin@192.168.50.254:/usr/local/cvs login

Logging in to :pserver:colin@192.168.50.254:2401/usr/local/cvs

CVS password:

CVSROOT variable

This is an environment variable used to specify the location of the repository we're doing operations on. For local use, it can be just set to the directory of the repository. For use over the network, the transport protocol must be specified. Set the CVSROOT variable with setenv

CVSROOT string on a csh, tcsh shell, or with export CVSROOT=string on a sh, bash shell.

# setenv CVSROOT :pserver:<username>@<host>:/cvsdirectory

For example:

# setenv CVSROOT /usr/local/cvs # Used locally only

# setenv CVSROOT :local:/usr/local/cvs # Same as above

# setenv CVSROOT :ext:user@cvsserver:/usr/local/cvs # Direct access with SSH

# setenv CVS_RSH ssh # for the ext access

# setenv CVSROOT :pserver:user@cvsserver.254:/usr/local/cvs # network with pserver

When the login succeeded one can import a new project into the repository: cd into your

project root directory

cvs import <module name> <vendor tag> <initial tag>

cvs -d :pserver:colin@192.168.50.254:/usr/local/cvs import MyProject MyCompany START

Where MyProject is the name of the new project in the repository (used later to checkout). Cvs

will import the current directory content into the new project.

To checkout:

# cvs -d :pserver:colin@192.168.50.254:/usr/local/cvs checkout MyProject

or

# setenv CVSROOT :pserver:colin@192.168.50.254:/usr/local/cvs

# cvs checkout MyProject

We need 2 shells for this. On the first shell we connect to the cvs server with ssh and

port-forward the cvs connection. On the second shell we use the cvs normally as if it where

running locally.

on shell 1:

# ssh -L2401:localhost:2401 colin@cvs_server # Connect directly to the CVS server. Or:

# ssh -L2401:cvs_server:2401 colin@gateway # Use a gateway to reach the CVS

on shell 2:

# setenv CVSROOT :pserver:colin@localhost:/usr/local/cvs

# cvs login

Logging in to :pserver:colin@localhost:2401/usr/local/cvs

CVS password:

# cvs checkout MyProject/src

Import

The import command is used to add a whole directory, it must be run from within the directory to be imported. Say the directory /devel/ contains all files and subdirectories to be imported.

The directory name on the CVS (the module) will be called "myapp".

# cvs import [options] directory-name vendor-tag release-tag

# cd /devel # Must be inside the project to import it

# cvs import myapp Company R1_0 # Release tag can be anything in one word

After a while a new directory "/devel/tools/" was added and it has to be imported too.

# cd /devel/tools

# cvs import myapp/tools Company R1_0

Checkout update add commit

# cvs co myapp/tools # Will only checkout the directory tools

# cvs co -r R1_1 myapp # Checkout myapp at release R1_1 (is sticky)

# cvs -q -d update -P # A typical CVS update

# cvs update -A # Reset any sticky tag (or date, option)

# cvs add newfile # Add a new file

# cvs add -kb newfile # Add a new binary file

# cvs commit file1 file2 # Commit the two files only

# cvs commit -m "message" # Commit all changes done with a message

Create a patch

It is best to create and apply a patch from the working development directory related to the project, or from within the source directory.

# cd /devel/project

# diff -Naur olddir newdir > patchfile # Create a patch from a directory or a file

# diff -Naur oldfile newfile > patchfile

Apply a patch

Sometimes it is necessary to strip a directory level from the patch, depending how it was created. In case of difficulties, simply look at the first lines of the patch and try -p0, -p1 or -p2.

# cd /devel/project

# patch --dry-run -p0 < patchfile # Test the path without applying it

# patch -p0 < patchfile

# patch -p1 < patchfile # strip off the 1st level from the path