I originally wrote this as a sort of cheat sheet to help a group of developers start using CVS. It cannot replace reading other material, particularly Version Management with CVS by Per Cederqvist.
See: http://www.cvshome.org/docs/manual/cvs-1.11.10/cvs_2.html#SEC9
Make the repository group-writable and group-exec, and have all the people that access it be a member of that group. If someone cannot create a lock file in a directory because someone else owns the directory, then they can't check out files; you may need to set umask for a user, or a sticky bit on the directory, in some cases.
Refer to the CVSROOT< in this style:
user@machine.name.or.ip:/path/to/repository
I usually do not set the $CVSROOT environment variable; I use several different cvs repositories, so I would be changing it, and it isn't needed anyway, because once you are in a checked out working copy of the code, you no longer have to specify the repository with -d.
cd into that directory, then run this command:
cvs import -m "Imported sources" repository-dir/module-dir some-name start
The source files will be kept in
$CVSROOT/repository-dir/module-dir. You don't necessarily need a module name, but it's easier to have one even if you have only one module.
If you want to use module names, finish defining the module with these steps:
cvs checkout CVSROOT/modules
cd CVSROOT
edit the modules file to have a line such as:
modulename repository-dir/module-dir
cvs commit -m "Added the modulename module." modules
cd ..
cvs release -d CVSROOTIf you are working from a directory tree with RCS/ directories at every level, consider making a temporary copy without them, so you don't put the RCS directories in the CVS repository.
If files were previously in an RCS repository, and you need to maintain the change history, then after the step above, find the ",v" files in your RCS directory, and directly copy them over to your CVS repository; put them in the same directory as the source file itself (not a sub-dir named RCS), there will probably a ",v" file already there for you to overwrite.
Usually people do not keep non-ascii files in the repository. If you want to, add those separately with the flag "-kb" when you do the "cvs add" command.
cvs -d /path/to/cvs-root-of-repository/ co module-name
(if you did not use a module name, use "." )
Checking out a working copy on a remote machine
cvs -d username@machine.name.or.ip:/path/to/cvs-root-of-repository/ co module-name"co" is an abbreviation for "checkout", you can spell it out in full.
After initial checkout, you can run CVS commands from inside your working directory without specifying the -d option for the location of the repository.
One person can check out as many working copies (into different places) as they want. Multiple people can check out working copies for each to work on independently. There is a command to "release" a working copy back to the repository, but it's not necessary and no one ever uses it.
cvs diff
or
cvs diff filename
will produce a diff (suitable for making patches) between what you have in your working copy and what is in the repository.
To view a diff of the current working directory against the repository from 3 days ago:
cvs diff -D "3 days"
Most English descriptions of time are accepted and the format of the date as used by the "date" command also works.
cvs up
Updated files will be marked with a "U"
New files (on your side) will be marked with an "A". If you made
new files and they aren't marked with an "A", then you need to do
the "cvs add" command.
Files you deleted, and that will be deleted from the repository too
(the "cvs remove" command was used), will be marked with an "R"
Files you changes will be marked with an "M"
Files that both changed, and were merged, will also be marked with an "M"
Files that both changed, and had a conflict at merge, will be
marked with a "C" -- you need to edit these files, and look for
the area marked "<<<<<<" before committing
Files cvs doesn't know anything about will be marked with an "?"
cvs commit filename
or
cvs commit -m "short note about changes" filename
To commit your whole working directory, just do
cvs commit
in the top level of the directory tree.
cvs rtag release-4-Jan-2003 .
The "release-4-Jan-2003" can be anything.
http://cvsbook.red-bean.com/ This one is also good, and available in paper. http://www.wincvs.org/ WinCVS is a graphical client that allows you do to all of this from a GUI; it has versions for Windows, Linux, and Mac. Often, when a team is switching to CVS the windows based members (which might be all the non-coders) feel nervous about possibly not being able to track and follow changes in the code. A GUI CVS client for windows can be very reassuring.
Chora is a web front end to CVS that is part of Horde, a package a number of web based applications. There is a demo of it linked to from the Chora page, so you can see what it looks like. If a team of people are switching to CVS, setting this up can be important because it gives even the people who don't know how to use CVS the ability to track what is going on.
There are ways to make CVS automatically send emails or do other things every time there is commit, or on other events; most of the time that's not necessary, and people monitor what is happening by doing a
cvs update
on a regular basis.
You may find that you want to make branches of your code development; in this case you should read the Per Cederqvist manual on that, but the basics is that you just add -b to a tag command, and the working copy is thereafter "stickily" attached to that branch:
cvs tag -b compiles-on-RH7-only .