Quick Guide to CVS
In case someone else has edited a file on which you are working, use the
Update feature to have CVS merge all changes into your working copy. A conflict
only occurs when changes were made in parallel to the same part of a file. To
avoid this, remember to run the Update feature before checking in a file.
Other users can be told who is working on what file through the watches feature.
Edit $CVSROOT/CVSROOT/notify (to tell CVS how to perform notifications), and
$CVSROOT/CVSROOT/users (list of e-mails addresses.). The former should include
ALL mail %s -s "CVS notification", and the latter should contains
lines such as the following: kapil:email@example.com . The user name (kapil,
here) should be listed in the CVSROOT/password file. It's possible for users
to only receive notifications when only a specific action has been done on a
file, by running eg. $ cvs watch add -a commit hello.c . Watches can be removed
by running eg. $ cvs watch remove hello.c
To roll back to a previous version of a project, run eg. cvs checkout
-D '1 year ago' preproject . To retrieve a specific revision of a file, run
eg. cvs checkout -r1.4 preproject.
- Import: Creating a new project by adding files into the CVS repository
- Checkout: Download a project or a specific revision of a file out of
the CVS repository into a local directory
- Export: Same as checking out a file, without the CVS administrative
directories; Used to obtain a clean distribution
- Commit: Upload changed files into the CVS repository; Each file will
be given a new revision number
- Checkin: Synomym for commit
- Upload: Synonym for import or commit
- Download: Synonym for checkout or export
- Create the repository using cvs -d /usr/local/cvsroot init
- Set the CVSROOT env't variable $ export CVSROOT=:pserver:firstname.lastname@example.org:/usr/local/cvsroot
- Either launch CVS as a stand-alone process, or edit inetd/xinetd to
launch CVS on demand. If using inetd, edit /etc/inetd.conf and /etc/services
2401 stream tcp nowait root /usr/local/bin/cvs
cvs -f --allow-root=/usr/cvsroot pserver
Rememer to refresh inetd (eg. killall -HUP inetd)
- To allow remote users to connect to the repository, edit $CVSROOT/CVSROOT/passwd,
which should look something like this:
are hashed with the usual Unix crypt() function call.
Note: To tell
CVS not to check /etc/passwd (or /etc/shadow?) for user passwords, edit
$CVSROOT/CVSROOT/config, and add SystemAuth=no
- To connect to a remote CVS repository in command-line mode, run cvs
-d :pserver:email@example.com:/usr/local/cvsroot login
- To check out a project, run cvs -d :pserver:firstname.lastname@example.org:/usr/local/cvsroot
- To set up a read-only repositor for authenticated users, either list
those users in $CVSROOT/CVSROOT/reader, or list users with write access
privilege in $CVSROOT/CVSROOT/writers. Both files look like this:
- To add files in a given project (someproj, here), run cvs import -m
"Added this to the someproj project" someproj vendor rel1-1, where
"vendor" is a vendor tage, and rel1-1 is a release tag.
- Add read or write locks (NEEDED?)
- To set a label to a file revision, run cvs tag rel1-1 file.c
- To view the tags and which revision number they represent for a given
file, run cvs status -v file.c
- To check out any revision of a module, run cvs checkout -r rel1-1 module1
- To check in changes, run cvs update on your local project copy to sync
it with what is in the repository (to prevent conflicts), and run cvs commit.
CVS will fail if someone else has already checked files in before you did.
- Decide where the CVS file repository will live, eg. /usr/local/cvs
- $ export CVSROOT=/usr/local/cvsroot
- $ cvs init . This will create the directory $CVSROOT/CVSROOT, which contains administrative information for the CVS system.
- Import a directory, eg. cd /usr/local/www/community ; cvs import -m "community" community mfre base
- To remove a file from the repository, run eg. cvs remove file.html
The -m tag provides a description for the imported files; this is followed by the name of the directory in the repository, a "vendor tag" containing information about the software vendor ["mfre"] and a "release tag" containing information about the current release of the software ["base"].
The first time you import files into your source tree, CVS assigns them all a version number of 1.1. This version number is automatically incremented on a per-file basis as changes are made.
typically, all developers who will be working on the source tree need read and write access to the source tree directory in the
repository. The easiest way to accomplish this is to create a new "group" with the groupadd command.
$ cvs checkout community
If you need to quickly refresh your working directory with the latest source tree, use the "cvs update" command:
$ cvs update
The "cvs update" command also works with single files - to get the latest version of the file "lib.php3", you could use:
$ cvs update lib.php3
The "cvs update" command typically prints a one-letter indicator next to each file - this could be
U file has been updated
M file has been modified
A file has been added to your working directory
R file has been removed from your working directory
C conflict detecten when trying to merge file into source tree
But don't stop there - remember, this is *your* version of the source tree and the CVS repository has no knowledge of the changes you have just made. So tell it, by committing your revised code back to the repository with the "cvs commit" command (note that you'll be asked for a comment describing the changes you made):
$ cvs commit
$ cvs status functions.php3
$ cvs add sql.php3
$ rm index.php3
$ cvs remove index.php3
Since CVS changes revision numbers on a per-file basis, it's unlikely that all the files in your project will have the same revision number. If you'd like to stamp all the files with a specific revision number (commonly seen immediately prior to a software release), you can use the "cvs commit" command, like this:
$ cvs commit -r 2.0
For example, if you remember, you assigned the initial source tree a release tag of "base". Now, if you wanted to go back to square one and
start off from the initial source tree, you could check out the "base" release like this:
$ cvs co -r base community
Or, if you're at release 3.8 of a piece of code, you could tag all the files at the point like this:
$ cvs tag release-38
And, if at some time in the future you need to extract an image of the files at the time of "release-38", you can use:
$ cvs co -r release-38 community
You can use the "cvs update" command to accomplish the same thing:
$ cvs update -r release-38 community
What's the difference between add and import when uploading new files to
a CVS repository?