1 Einstein Drive Princeton, NJ 08540, USA
Bloomberg Hall 1 Einstein Drive Princeton, NJ 08540, USA
1 Einstein Drive Princeton, NJ 08540, USA
CVS - Concurrent Versions System
Consider using Subversion rather than CVS.
CVS is a highly effective method to develop software or documentation. For more than a small number of people making changes to a file it becomes essential to maintain a history of changes; you might wish to retrieve an old version of the file to fix a bug for example. You might also wish not to overwrite another users changes by accident. CVS makes this all possible.
CVS is available on our systems under Solaris and Linux.
There are notes below to help you get started using CVS at SNS Computing. They are no substitute for the CVS Manual located here, but they are a lot less extensive. There are many ways to set up CVS; these notes document our recommended method.
For those familiar with CVS already, a best practices document is located here.
A web based CVS tool is available here for viewing code repositories that are managed using CVS. Repositories linked to this page appear read only (you can't do CVS commits). If you are maintaining a local CVSROOT and wish it to be included, please let the computing staff know the following:
1) A short name for the repository. 2) The location of the CVSROOT. 3) A long name for the repository.
NOTE: We do not run cvspserver at SNS Computing. If you require CVS access for someone who does not have an SNS computing account, please contact the computing staff.
Creating a CVS repository
A repository is a place in CVS where projects get stored. You might not need to create one, because you might be working on a project that already exists in a repository somewhere, or you might be placing your own project in a repository which already exists.
Creating a repository is simple enough though.
First, make sure that your top level directory (either /home or /work) has execute permission for group (drwx--x--x). If not, set permissions as follows:
chmod 711 /home/username or chmod 711 /work/username
Let's make a repository under /home/jns/cvs as
follows:
bash-2.05a$ mkdir /home/jns/cvs bash-2.05a$ cvs -d /home/jns/cvs init
Inside the repository there is now a directory called CVSROOT which contains various administrative files:
bash-2.05a$ ls /home/jns/cvs/CVSROOT checkoutlist config editinfo loginfo notify taginfo verifymsg,v checkoutlist,v config,v editinfo,v loginfo,v notify,v taginfo,v commitinfo cvswrappers Emptydir/ modules rcsinfo val-tags commitinfo,v cvswrappers,v history modules,v rcsinfo,v verifymsg
NOTE: The CVSROOT environment variable (if defined), defines the repository itself. If someone talks about the CVSROOT they are referring to the repository also. $CVSROOT/CVSROOT refers to the administrative directory within the repository.
Repository Permissions
A group of people working on a project should be defined by a unix group, which the project members are part of. The computing staff will need to set this up for you.
File and directory group ownership in the repository should be by the unix group. Let's say a unix group called cvsproject has been created. For the repository we created above we need to execute:
bash-2.05a# cd /home/jns bash-2.05a# chown -R jns:cvsproject cvs
If you wish to allow other members of the cvsproject group to administer project's within the repository (and you might well not) then the repository, and also directories in the repository, should be what's know in UNIX permissions parlance as sgid (i.e. the 's' bit is set for group permissions). This ensures that files created in those directories obtain group ownership from the parent directory and not the users default unix group. We set this requirement as follows:
bash2.05a# cd /home/jns bash2.05a# chmod g+wsx cvs bash2.05a# chmod g+wsx cvs/CVSROOT
You may wish to remove read permission from all users not part of the project. To do this in our case we execute
bash2.05a# chmod -R o-rwx cvs
Importing a project into the repository
Lets say we wish to import files from the directory
home/jns/project into cvs. We would execute the
following:
bash-2.05a$ cd /home/jns/project bash-2.05a$ cvs -d /home/jns/cvs import -m "Imported Shell Scripts" shell-scripts jns start
In the above, '-d /home/jns/cvs' specifies the
CVSROOT for the project, shell-scripts is the name
of a directory that the scripts will appear under in CVS, and
jns is a vendor tag (you might just use your user
id). start refers to the creation of a project.
A directory called shell-scripts now exists in
the CVS repository which contains all the files and directories
under /home/jns/project.
bash-2.05a$ ls /home/jns/cvs CVSROOT shell-scripts bash-2.05a$ ls /home/jns/cvs/shell-scripts/ a2print,v ferret_paths,v package_list,v shove_mail,v backup_devices,v file_permissions,v path_check,v shove_public_html,v backup_etc,v find_hidden_files,v pkginstall,v shove,v backup_home,v find_rhosts_files,v port_forward_detect,v ssh_upgrade,v backup_rsync,v ftp_multi,v ps_to_img,v symbolic_links,v backup_system,v ftp_one,v remote_orig,v tilde,v backup_usrlocal,v get_docs,v remote,v uncr,v core_search,v gfdl_linux remove_secret_tilde,v whatis,v cron_jobs,v hardcopy,v rpm_verify_script,v which2,v cyclopes,v ncp,v run_pine,v xauth_merge,v dircmp,v nologin,v run_procmail,v xroot,v dir_copy,v output shove1,v
NOTE: You should NEVER edit the files in cvs directly. Instead, you first check out the repository, edit the files there, and check it back in using CVS as described below.
Correcting permissions on imported project sources
Once a set of project sources has been imported, you should correct the permissions to allow the other group members to make changes. As when creating the repository itself, we need the sgid permissions bit set on all the project directories.
For the bash shell we accomplish this by executing
bash2.05a# for dir in `find shell-scripts -type d`; do
`chmod g+s $dir`; done
The equivalent command in csh or tcsh is
tcsh# foreach dir (`find shell-scripts -type d`); `chmod
g+s $dir`; end
Checking out a project
Before modifying the files in a project, you must first CVS checkout the project sources.
The repository itself may be local (both you and the project repository are within SNS computing), or remote (either you or the project is not in SNS computing).
(1) Local repository
As an example, we are going to CVS checkout the shell-scripts
project into the directory /home/jns/cvswork
bash-2.05a$ cd /home/jns/cvswork bash-2.05a$ cvs -d /home/jns/cvs checkout shell-scripts
(2) Remote repository
We are on a computer outside SNS which has CVS, and wish to CVS checkout the shell-scripts project:
Firstly, we need to set an environment variable that tells CVS
to use Secure Shell (ssh) as the transport protocol. In the bash
shell we do this with the command 'export
CVS_RSH=ssh'. In csh or tcsh the equivalent command is
'setenv CVS_RSH ssh'.
Now we can checkout the repository:
bash-2.05a$ cvs -d
:ext:jns@rogue.sns.ias.edu:/home/jns/cvs checkout
shell-scripts
In the above, '-d
:ext:jns@rogue.sns.ias.edu:/home/jns/cvs' tells SSH to
authenticate to the remote machine rogue.sns.ias.edu as user jns,
and CVS should obtain the project under the repository
/home/jns/cvs.
To checkout projects to an SNS computer from a remote repository, follow the guidelines laid down for that repository.
Checking in a project
Lets say you have modified a file. As an example, we might have modified the script dir_copy in the checked out shell-scripts project. It's time to commit the change to the repository as follows:
bash-2.05a$ cvs -d /home/jns/cvs commit
dir_copy
When this command is executed, an editor opens (the environment variable $CVSEDITOR determines which, or if it isn't defined, operating system defaults take over), in which you should add text to describe the change. When you exit the editor the file will be committed to the repository.
For small changes, rather than opening up an editor one can simply specify the log message on the command line if desired. e.g.
bash-2.05a$ cvs -d /home/jns/cvs commit -m "Added a
comment line" dir_copy
Cleaning up
Rather than deleting the checked out working copy of shell-scripts, one should issue a CVS release to make sure there have been no changes that have not been commited:
bash-2.05a$ cd /home/jns/cvswork bash-2.05a$ cvs -d /home/jns/cvs release shell-scripts You have [0] altered files in this repository. Are you sure you want to release directory `shell-scripts': y
To release AND also delete the working copy:
bash-2.05a$ cvs -d /home/jns/cvs release -d shell-scripts You have [0] altered files in this repository. Are you sure you want to release (and delete) directory `shell-scripts': y
You might see errors indicating that a checked out file has been changed. For instance
bash-2.05a$ cvs -d /home/jns/cvs release -d shell-scripts M dir_copy You have [1] altered files in this repository. Are you sure you want to release (and delete) directory `shell-scripts': n ** 'release aborted by user choice.
In this instance you would firstly examine the differences between the working copy of dir_copy and the repository:
bash2.05a# cvs diff dir_copy
At this stage, you'll probably remember you made a change to this file and be able to commit and then release it.