How to Deploy CVS (Concurrent Versions System)

CVS is a version control system, an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents.

Client Server Architecture:-

CVS uses client-server architecture: a server stores the current version(s) of the project and its history, and clients connect to the server in order to check out a complete copy of the project, work on this copy and then later check in their changes. Typically, client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers.

Terminology

A single project (set of related files) managed by CVS is called a module. A CVS server stores the modules it manages in its repository. Acquiring a copy of a module is called checking out. The checked out files serve as a working copy. One's changes to the working copy will be reflected in the repository by committing them. To update is to acquire the latest changes from the repository in the working copy.

• 'Module' - a particular set of files kept in CVS.
• 'Repository' - Location on CVS server where modules are kept.
• 'Revision' - A certain version of a file.
• 'Tag' - A certain milestone in a file or module's development.
• 'Branch' - A 'fork' of the module.

How to install CVS


On RPM based distribution you can use YUM or RPM to install CVS.
rpm -ivh cvs
or
yum install cvs

Then you need to create a user who is responsible for cvs management.


User Creation:-

There are many ways of user creation in cvs.
The CVS server can be made to authenticate from a password file in the CVSROOT module. All you need to do is add a file into the CVSROOT module. Create a file in there, called 'passwd'.
Entries in this file should be of the form:
desiredusername:EnCrYpTeDpAsSwOrD:realuser
The first’s entry in this colon-separated list is the desired username to allow. The second entry is the password for that user, done in standard unix crypt() format. The third entry is the real UNIX user on the server that file operations will be done as (so, you can set up a user that can write to just the repository and nothing else). If you have apache installed, there's a utility called 'htpasswd' which can generate the first 2 fields for you. You can then add the third field manually.


htpasswd /cvs/reposName/CVSROOT/passwd

User Deletion

For user deletion simply go to the CVSROOT passwd file and remove the user name from there.

For disabling the user put a hash (#) make in front for the username.

Creating a Repository


Create a 'cvsadmin' user #adduser cvsadmin
Login as 'cvsadmin'

cvs -d  <#pathToHomeDirectory#>  init

here pathToHomeDirectory is the path of repos wherever you want to be (you must have write permission to that location)
-d is for directory

It will create a CVSROOT folder under the reposName which contains various administrative files which controls CVS behavior

Deleting a Repository

It is as simple as
1. #rm –rf #RepositoryName# (But it is not recommended)

2. In a sandbox if you issue
cvs remove -f file_nolonger_needed
cvs commit
this will mark the file in the repository as removed at the current and into the future, and it will remove the file from your current sandbox.

You should be aware that directories are not really managed by CVS so you can't remove them, but if you remove everything in them and use the -P on updates they are effectively removed.

Authentication:-

When a remote cvs client uses the pserver method to connect to a repository, the client is actually contacting a specific port number 2401. It is default port for cvs pserver.

The server will start as soon as it see a connection request from the client.

Put a line in the /etc/services as
Cvspserver 2401/tcp

Now for authenticating you have to manually create “passwd” files under the CVSROOT.
Its format should be like this :-

::

If you want to give read or write access separately then you have to create two more files under CVSROOT manually named as “readers” and “writers”.

Readers contains list of users who can only read the repository
Writers contains list of users who can read and write the repository

** If same username listed on both the files then cvs gives him only read only access to the repository



User Privileges

Next thing you might want to do is only allow specific users (i.e. your developers) to write to the CVS repository.
To allow only certain users write access to the repository, place their usernames in a file called 'writers' in the CVSROOT module

Backing up a repository

There is nothing particularly magical about the files in the repository; for the most part it is possible to back them up just like any other files but make sure that no one is working at that time.

tar -cf #backupName.tar

Create a file "cvs" under xinetd.d as shown below.

[cvs@cvs ~]# cat /etc/xinetd.d/cvs
# default: off
# description: The CVS service can record the history of your source \
# files. CVS stores all the versions of a file in a single \
# file in a clever way that only stores the differences \
# between versions.
service cvspserver
{
disable = no
port = 2401
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
env = HOME=/var/cvs
server_args = -f --allow-root=/var/cvs pserver
# bind = 127.0.0.1
}

Tips:-

1. Replace bind =127.0.0.1 with the actual IP of your server.
2. If you want to get the logs in a separate file then define that as well. eg. log_type = FILE /var/log/cvspserver


Restart the xinetd server
service xinetd restart