My experiences setting up CVS ***************************** Copyright (c) 2000, Jonathan Marks, all rights reserved. All un-annotated page refs are to Per Cederqvist's manual, 1.10. This doc is not a substitute for the manual, it suggests a structured way of using cvs, that's all. Presently only a local site, no client/server commentary yet. Watch this space. As root: 1. Create logins: cvs and cvsguest 2. Create groups: cvs and cvsadmin (p87) 3. Make login 'cvs' a member of the 'cvs' group and a supl. member of cvsadmin. 4. Make the appropriate users and cvsguest supl. members of the cvs group. 5. ensure umask is set to 002 globally (except for root). (Done through /etc/profile if using bash). 6. Change the file permissions and membership of cvs (usually in /usr/bin) chgrp cvs /usr/bin/cvs chmod 2750 /usr/bin/cvs The reasons for doing this. 1. cvsadmin group only belongs to cvs for admin commands. 2. the repository is going to have rw gid group permission of 'cvs' so that all appropriate users can access and update files in it. 3. We have a guest account that we will set up for read only access. 4. Now cvs can only be seen and executed by members of the cvs group and sgid to 'cvs' to execute this command. The net effect of this is: * Added security - only members of the cvs group can use cvs commands. * All files transferred in and out of the repository are written with the cvs group. Still as root carry out the following (p7): 1. cd /usr/local mkdir cvsroot #chmod 770 cvsroot // not sure this is necessary chgrp cvs cvsroot // not sure this is necessary 2. Add CVS root to the environment variable during login. (Using bash, I add the following line to profile: export CVSROOT=/usr/local/cvsroot Now we initialize cvs as login 'cvs' to ensure gid of 'cvs' for repository 1. cvs -d /usr/local/cvsroot init This will initialize the repository. We need to modify some cvs system files 1. In cvs's home dir: mkdir CVSROOT ; cd CVSROOT 2. edit a file '~/CVSROOT/writers', adding to it the list of developers who are permitted to check files into the repository. Make sure 'cvsguest' is *NOT* included in this list one user name per line, and remember to leave a blank last line (CVS is fussy!). 3. Additional files to ignore: our build environment creates 'bak' directories where editor backups of files are kept. Also the build process generates a number of file .bld*, which are maintained in the source tree directories. Both of these need to be ignored. The build environment also generates 'lib' and 'bin' directories, if these directories exist, in most cases we do not want to check bins and libs into the repository. The latter two directories we exclude explicitly in the 'import' command. the former we do implicitly in the ~/CVSROOT/cvsignore file, by adding 'bak' and '.bld*' to it. 4. We need to identify these two files as cvs system files. These files do not exist in the default cvs install. We do this by checking out 'checkoutlist, and adding these files to the list. cd ~ # to get to /home/cvs cvs co CVSROOT/checkoutlist 5. # Add to checkoutlist writers cvsignore 6. cvs ci CVSROOT/checkoutlist. 7. cvs add CVSROOT/writers CVSROOT/cvsignore 8. Give some thought to the organization of the information to be stored in the repository, off /usr/local/cvsroot. I chose a three tier structure comprising: ./company-name/nature/instance/. . . For example /usr/local/cvsroot | +--novatek | | | +--config | | | | | +--gateway # name of a workstation | | | (mimic dir structure /usr, /etc and store | | | config files that differ from defaults) | | +--henry # name of another work station | | | (ditto) | | | - - - - - - - - - - | | | +--proj | | | | | +--rmk | | | (source directory structure of project) | | | | | +--other-proj | | | (ditto) | | | - - - - - - - - - - | | | +--websites | | | | | +--this-site | | | (website source files/tree) | | | | | +--that-site | | | (ditto) | | | - - - - - - - - - - | +--next-co.-or-org. | | - - - - -and so on . . . . 9. The cvs concept of modules permit us to specify these long directory hierarchies in the repository using a short form, and store them in the users working area under the short form directory. cvs keeps a CVSROOT/modules system file for this purpose. By doing the following as login cvs: cd ~ cvs co CVSROOT/modules Add the following to the file rmknovatek/proj/rmk cvs ci CVSROOT/modules Now a 'cvs co rmk', will check out the whole ./novatek/proj/rmk in the repository to ./rmk in your working area. Now is the process of checking a project in for the first time. For this we use the import command. We have a working source tree, and nothing in the repository yet. Lets assume the working source tree is rooted in a directory ~/xyz/pqr/abc/rmk of the user jon. 1. cd ~/xyz/pqr/abc/ 2. cvs import -Ibin -Ilib -m "Created" novatek/proj/rmk rel-0-00-br rel-0-00 ignore these, message repository root br tag tag off br On an import cvs automatically creates a branch off the initial head. This is great when tracking updates in third party (vendor) software, where we have also made changed, but serves little purpose for a simple checkin. Remember that cvs is sgid cvs, so all the files will be deposited in the repository with the cvs group. 3. Look at p27 on checking the input. 4. To change the directory structure and add or remove files, use the 'cvs add' and 'cvs remove' commands. Note that the first time files are checked out after an import there version numbers are 1.1.1.1 not 1.1! This is evidence of the branch being created on import, but to me it looks like a bug. When the files are checked in again they are checked in with revision 1.2. Please let me know if you have an opinion on this. "jon.marks@novatek.co.nz". I am happy for you to include this file in its entirety on web sites, with the copyright notice. However my preference is for web sites to link to it at: http://www.novatek.co.nz/linux/config/cvs . SETTING UP A REMOTE SERVER ************************** (With not very secure password protection) See page 27 of the manual. Add the following line to /etc/services >>>>>>>>>>>>>>>>>>>>>>>> cvspserver 2401/tcp <<<<<<<<<<<<<<<<<<<<<<< Add the following line to /etc/inetd.conf >>>>>>>>>>>>>>>>>>>>>>> cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/usr/local/cvsroot pserver <<<<<<<<<<<<<<<<<<<<<<< Then do a "killall -HUP inetd" In my installation the cvs server is installed on a box behind an ip masqerading firewall. This means that all tcp traffic on port 2401 needs to be forwarded from the firewall to the appropriate ip address. I use a linux box as a firewall (see gateway config), and add the following line to /etc/rc.d/rc.firewall on the firewall box. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /usr/sbin/ipmasqadm portfw -a -P tcp -L 24.113.98.164 2401 -R 192.168.0.3 2401 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Now it should be easy for people to login. For read only access I have created a login "cvsguest" with password "cvsguest". To login: cvs -d :pserver:cvsguest@cmex.org:/usr/local/cvsroot login You will be prompted for a password, enter "cvsguest" Retrieve your desired module with: cvs -d :pserver:cvsguest@cmex.org:/usr/local/cvsroot co where is the desired module to retrieve. If you want to check files in or want write access to the cvs tree, contact me at jon@cmex.org.