CVS Server setup | CVS test | SSH tunneling | CVS usage Server setup 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 # cd /root # 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 (default port: 2401/tcp). 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 user2:vnefJOsnnvToM:cvs Test it 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:@:/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 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 SSH tunneling for CVS 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 CVS commands and usage 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