cvs notes

Cvs notes:
Sandbox: A sandbox is a local copy of a project’s files.
Repository:

When you create a sandbox, you need to specify the repository to which to which it is connected. You do this by setting the repository path, either by putting it in the CVSROOT environment variable on you client computer, or by declaring it in the –d command option when you check out the sandbox. CVS stores the repository path in the sandbox.

The cvs checkout command is used to create a sandbox. Once the sandbox is created, checkout no longer needs to be used sandox; update is the preferred command from that point..

Files are edited in the sandbox, but changes to the sandbox have no effect on the repository until the are commited. The cvs commit uploads changes from the sandbox to the repository.

The cvs commit command uploads changes to from the sandbox to the repository, cvs update downloads changes from the repository to the sandbox.

Creating a repository:
To create a repository, create the repository root directory on the computer that will act as the CVS server and ensure that the root directory is owned by the user who will ultimately own the repository. Execute the command:
$> cvs –d repository_root_directory init
Where repository_root_directory is the name of your directory, to setup that directory as a CVS repository. The root must be given an absolute path, not a relative path.

Note: ensure there is enough room for three times the expected final size of the project
If you intend to store binary files then five times the size.

Securing the project.
Sandboxes are checked out of the repository with the username of the user who creates them or does the checking out.

Repository Root Directory:
Secure the repository root directory so that only users who are allowed to create new projects have write access. Users who will be using existing repository projects, even though they may creating and writng to projects files should only have read access to this directory.

Project Directories:
Group ownership of project files and directories controls project security. Ensure that each project is group-owned by a group with appropriate membership, and set the group permissions for the project files to the project’s group.
In UNIX or linux set each directory’s SGID bit to ensure that any new files or directories created in the directory are created with the same group ID as the directory the are created in. Use the command chmod g+s directory to set the SGID bit.

Repository Structure:
A CVS repository is composed of the special CVSROOT administrative directory and any project directories you create. All the CVS administrative files and configuration files are kept in CVSROOT.

CVS Subdirectory:
The only file stored in the CVS subdirectories in a repository is fileattr. Which lists the file attributes of the files in the parent directory.

Locks:
CVS uses read and write locks to prevent processes from simultaneously writing to or reading from the same repository files. These locks are signaled by the presence of a file or directory with a specific name patter in project directories.

CVSROOT Files:
The CVSROOT directory contains administrative files that contain information about the project stored in CVS.
It is good practice to have a specific username to own the CVSROOT directory and the repository root directory, and to be the initial owner of the CVSROOT files.
Create a group to have the group ownership of the CVSROOT directory and files, and include only trusted people in that group.

Configuration Files:

Config:
LockDir=directory
CVS puts lock files in the nominated directory rather than in the repository. This allows you to set the repository directories read-only for people who should not be commiting changes.
LogHistory=value
The text in value controls which actions are logged to the history file in the repository’s CVSROOT directory. The valid values are any combination of the following letters:

A Log when a file is added to the repository.
C Long when a file would have been updated in a sandbox, but needed to be merged and there where conflicts in the merge.
E Log when a file or files are exported.
F Log when a file or files are released.
G Log when a file is updated in a sandbox with a successful merge.
M Log when a file si modified (a sandbox revision is added to the repository).
O Log when a file or files are checked out.
R Log when a file is removed from the repository.
T Log when a file or files are tagged or rtagged.
U Log when a file is updated in a sandbox with no merge required
W Log when a file is deleted from a sandbox during an update because it is no longer active in the repository.

RCSBIN=directory

SystemAuth=value
This option is useful only if the client connects to CVS in pserver mode. It applies to CVS Versions 1.9.14 and later. If value is yes, the server authenticates the connecting user with the passwd file in the repository’s CVSROOT directory. If the user fails to authenticate there, the server authenticates the user against the main user database for the operating system.

If the value is no, the server authenticates the user only against the passwd file.
The default is yes.

Modules:
The modules file contains information about projects in the repository and can group arbitrary files or directories into a single module.Information in this file must be created by the repository or project administrator; CVS does not update this file when a new project is imported. Once a module is defined, the project and directories it defines can be checked out into a sandbox using either the module name or the name of the repository directory it represents.

Backing Up A Repository:

A CVS repository can be backed up using the same backup tools and schedule that you use for ordinary text and binary files.

Quick start guide I have used successfully:

1. Create a CVS user (for example 'cvsuser') using useradd. This will also create a group called 'cvsuser' which will be used to grant CVS access to other users.
For example:
[jdavis]$ su root
Password: {enter password}
[root]# /usr/sbin/useradd -c 'CVS root user' cvsuser
[root]# passwd cvsuser
New password: {enter password}
Retype new password: {enter password}

2. Create a folder for the initial repository using the 'cvsuser' account, or chown / chgrp it to 'cvsuser'.

[root]# mkdir /cvsrepo
[root]# chown cvsuser /cvsrepo

3. Set the 'group sticky bit' on all directories used by CVS (See "CVS File Permissions").
[root]# chmod g+s /cvsrepo
4. Initialize the repository using cvs init
[jdavis]$ su cvsuser
Password: {enter password}
[cvsuser]$ cvs -d :local:/cvsrepo init
5. Set up the lock directory
This is an important step. If lock directory is not set, the CVS daemon will try to create lock files in the repository directory, which will result in 'failed to create lock directory' error message when users perform any operations on the repository.

Create the lock directory first. For example:
[root]# mkdir /var/lock/cvs
[root]# chgrp -R cvsuser /var/lock/cvs
[root]# chmod -R g+w /var/lock/cvs
Then, configure CVS to use the lock directory. Change to a temporary directory, for example /home/cvsuser (which was created by the useradd command above), and check out the CVSROOT module from the repository using the local filesystem mode (not pserver mode). Edit the CVSROOT/config file and either uncomment or add a line 'LockDir=/var/lock/cvs'.
[root]# cd /home/cvsuser
[root]# cvs -d :local:/cvsrepo co CVSROOT
[root]# vi CVSROOT/config
... uncomment or change the line that defines LockDir...
for example: LockDir=/var/lock/cvs
[root]# cvs -d :local:/cvsrepo commit CVSROOT
6. Set up the cvs daemon:

for systems that use inetd - Add a line to the /etc/inetd.conf file

cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/cvs pserver

Make sure /etc/services contains the line

cvspserver 2401/tcp

for systems that use xinetd - Create a 'cvspserver' file:
Sample /etc/xinet.d/cvspserver file
service cvspserver
{
socket_type = stream
wait = no
user = root
group = cvsgroup
env = HOME=/cvsrepo # Fixes RHL 7.0 problem!
server = /usr/bin/cvs
server_args = -f --allow-root=/cvsrepo pserver
disable = no
}
7. Restart inetd (or xinetd).

[root]# /etc/init.d/xinetd restart