CVS Administration
Pages: 1, 2
Removing Directories
|
Related Reading
|
Directories cannot be removed from the repository using CVS commands. If a directory is no longer required, empty the directory with cvs remove, and use cvs update -P and cvs checkout -P when retrieving a working copy. The -P flag ensures that empty directories are not retrieved.
If you must, you can remove a directory by using rmdir on the repository. Do this on a copy of the repository first and check that you aren't breaking anything: If the directory in the repository has an 'Attic' subdirectory, you will lose archived copies of files formerly stored there.
If you remove a directory from the repository, you should have all your users remove their existing working copies, and check out fresh copies of the module.
Watching and Locking Files
Unlike many versioning systems, CVS doesn't have file locking--it doesn't prevent simultaneous editing of files. However, you can set files to be watched, so CVS will mail watchers when a file is being edited.
If files are being watched, developers need to use cvs edit and cvs unedit to release a file for editing. Unwatched files can be edited without notifying CVS in any way.
To set up files for being watched, use:
cvs watch on (files)
cvs watch off (files)To set yourself as a watcher, use:
cvs watch add (files)
cvs watch remove (files)or
cvs watch add -a edit|unedit|commit|all (files)
cvs watch remove -a edit|unedit|commit|all (files)The special CVS file notify determines what occurs when a watched file is changed. It defaults to sending mail to the user's username, on the CVS server. If your users have other addresses, set up the file "users" in the repository's CVSROOT directory. Entries should be in the format user:email, one to a line.
jenn:jenn@cvs.example.com.auKeeping CVS Secure
Remote Repositories
If the repository is on the local machine, both access and security are fairly straightforward. You can set the $CVSROOT environment variable to the root directory of the CVS repository, or call checkout with the -d <directory> option.
If the repository is on a remote machine, it is necessary to tell CVS which machine it is on, and what method will be used to access the machine. There are several methods available, but for security and simplicity I prefer to use SSH. The syntax for defining a remote $CVSROOT is :method:[[user]:[password]@]hostname[:[port]]:/path/to/repository; for example, :ext:jenn@cvs.example.com.au:/usr/local/cvsroot
(Note that my info cvs disagrees slightly with what my copy of CVS actually does. I have included the syntax that works for me--a colon between the host and the path. Use the syntax that works on your system.)
To use SSH, we use the :ext: method. This method uses an external-to-CVS rsh or rsh-compatible program to communicate with the CVS server. To tell CVS to use SSH instead of rsh, set the environment variable $CVS_RSH to SSH. Ensure that SSH is set up on the server and on all clients, that SSH keys are generated, and that users have usernames and passwords on both machines. If the usernames are the same, the user@ part of the CVSROOT string is not necessary. If a standard SSH port is used, the port is not necessary.
cvs -d :ext:cvs.example.com.au:/usr/local/cvsroot checkout samplePermissions
The files in the repository are all read-only. Permissions to those files shouldn't be changed. To control access, use the directory permissions. Most administrators make a group for the people who should have access to the module, and ensure that the group has write access for the directory.
|
Previously in this series: Introduction to CVS -- Jennifer Vesperman explains CVS, the Concurrent Versioning System, which is a popular system for storing and version-controlling files. This first article is intended for folks who will be using CVS already installed on a system. Jennifer explains check-out, update, adding, merging, and other functions. |
If using a remote repository, set the root directory of the module setgid to ensure that all directories beneath it are made with the correct permissions. If using a local repository, $CVSUMASK can be set to control the permissions of files and directories in the repository.
Developer Machines
Securing the project involves securing the repository and securing all checked out copies--typically your developer's machines. It's not enough to ensure that the repository is safe and all transmissions are properly encrypted if someone can walk into your developer's office on his day off and burn a CD of your code. Maintain the usual physical and Net-based security for your development machines, prototype and demonstration copies, and any other places the code gets checked out to.
Final Words
Managing a CVS repository can seem like an extra task for an overburdened administrator, but the repository can save the day when the client decides that they do need that abandoned feature after all, or when a minor change to a configuration file has unforeseen side effects--three weeks later.
Further Reading
man cvsman 5 cvsinfo cvshas a good section on "What CVS is" and "What CVS is not." It's also a useful expansion on the manual. The "Repository" section discusses alternate protocols in more depth.- From the Big Scary Demons column: BSD Tricks: CVS
- Sourceforge has several articles on CVS. See sections 6 and 7 on the Sourceforge Site Docs page.
For Debian Linux users:
man cvs-makereposman cvsconfig
Jennifer Vesperman is the author of Essential CVS. She writes for the O'Reilly Network, the Linux Documentation Project, and occasionally Linux.Com.
Previously in this series:
Introduction to CVS -- Jennifer Vesperman explains CVS, the Concurrent Versioning System, which is a popular system for storing and version-controlling files. This first article is intended for folks who will be using CVS already installed on a system. Jennifer explains check-out, update, adding, merging, and other functions.
Return to the Linux DevCenter.
