In the past, you may have had the problem that while working on a piece of software, a bug crept in which wasn't there in the first place. At that point, it would have been nice when you had the previous version, so you could track the changes and locate the bug.
CVS (Concurrent Version control System) is a tool which can record the history of your files. CVS can also keep a log of who, when and why changes occurred. The concurrent part in the name mean, that it is possible for two or more colleagues to work on the same source file and still keep track of the changes. It does this by keeping a hierarchical collection of directories in a central place on your system, called a repository. In the end, these directories and their files can then be merged together to form a software release.
A more simple tool for tracking software changes is RCS. Its advantages are that it is simple to setup, useful for simple systems and concurrency (working on the same file) is eliminated. Here we will only talk about CVS. This is because although it is a little more complicated, it offers much more power.
You may want to set up CVS on your personal box. If it's not already installed, then there's a binary package available for your operating system. You can also follow the steps below to compile from source.
tar xvfz cvs-1.10.tar.gz cd cvs-1.10 ./configure make su make install
The last step copies the binaries and man pages to the appropriate locations (you may want to check the makefile before running this).
CVS needs a couple of environment variables. You probably want these in the systemwide /etc/profile, but they should at least be available in your local profile file. Add these lines (bash shells):
* export CVSROOT=/home/cvsroot
* export EDITOR=/bin/vi and then logout and login. Do a su to become root user.
Now this is finished, you need to decide which group of users can use CVS. You may want to create a special group cvsusers, but in the following steps, it is assumed that the group users can use CVS. So no changes are needed here.
Now choose an appropriate location for the cvsroot directory (where CVS does its bookkeeping). Maybe this can be the /home directory (actually, it was already assumed as this was defined by the $CVSROOT variable above). So (as root) now do:
Choose a directory where you want the central repository to be kept, and hand out the correct rights:
mkdir cvsroot chgrp -R users cvsroot/
With the following command, files which are added, are automatically owned by the group users:
chmod 2775 cvsroot/
Now tell CVS to create all the initial files:
cd cvsroot cvs init
The repository is now ready to rock. Now suppose the company starts some project. The sysop can then add a new group, add users to that group and create a directory tree in the cvsroot/ directory with the correct rights. Suppose our system operator has always maintained the system its website but now wants to throw the webstuff in CVS and delegate maintenance to the user austinpowers. First, create a group for that purpose:
# groupadd www
# usermod -G www austinpowers
Then, give permissions to our web developer:
# cd /home/httpd
# ls -lh
total 12
drwxrwxr-x 2 root root 4096 May 21 17:21 cgi-bin
drwxrwxr-x 14 root root 4096 Jul 1 17:48 htdocs
drwxrwxr-x 3 root root 4096 May 21 20:09 icons
# chgrp www * -R
# chmod g+srwx *
Then put the project in the repository and do the permission thing again. # cvs import -m "Main website" website CompanyName start
# cd /home/cvsroot
# chown root.www website/ -R
# chmod g+s website/
If no errors are given, setup has succeded! Congratulations.Note that local users also can set up their own personal repository. They can make a cvsroot/ directory in their homedirectory, do a export CVSROOT=~/cvsroot and do cvs init. Then they are set to do the CVS thing for themselves.