cvs
CVS is a basically an improved multiuser RCS package. I am providign a list of common flags. For more complete information look at the man pages on cvs.
Starting a new repository
Set CVSROOT
If you don't you must pass the directory to specify the repository location on all cvs commands ( I explain this more in the section on CVSROOT ). For my own I just add the export command to my ".bash_profile" :
export CVSROOT=${HOME}/cvsroot/
You then want read that in to update the environment, like this :
source ~/.bash_profile
Initialize the repository
You need to create/setup the repository, like this :
cvs init
These steps only need to be done once for each repository, not project. You may endup having multiple repositories, so you may need to change your CVSROOT to switch repositories.
Starting a new project ( import )
Use import to start a new project
cvs import project_name vendor start
vendor and start are tags, don't get to worried about them just yet, but you must provide two tags ( a vendor tag and a start tag, I just call them vendor and start ). You will use the project_name for several other cvs commands ( the project name must be unique within the repository ).
You should get rid of the directory your code was in, since it is all in the repository and should now be checked out.
Checking code out ( checkout, co, get )
To get code from the repository, do this:
cvs get project_name
This will get all of the files and create the directories for you. It will put them in a directory with the same name as project_name. This copy of the code is usually referred to as a sandbox ( since you are going to play with it ).
Checking code in ( ci, com, commit )
If you are in the sandbox for the project, you can omit the project_name, otherwise you need to list it.
cvs com
This will update any changes to the repository. If you added new files, it will not do this however, there is a seperate command for that. This is so you don't accidentally check in executables or output files.
Adding files to a project ( ad, add, new )
If you need to add files to an existing project, since checkin does NOT do this for you.
cvs add filename
You can use wildcards instead of the filename, and it is smart enough to realize which files already are in the project.
NOTE: adding a file does not do a commit/check in, so do that after adding the file(s).
Releasing code ( release, re, rel )
When you are done with a project, you will not need a repository copy, and a working copy. To eliminate the working copy we use the release command.
Change directory to one above the working copy and type :
cvs rel -d project_name
The "-d" here actually removes the working copy, otherwise you can use rm to do this.
Tagging a project ( ta, tag, release )
This assigns a named tag to the committed source code.
cvs tag tag_name
You can use any name for a tag. This is required for the export and branch commands.
If you want to see all of the tags on a project use
cvs status -v
I usually pipe that into less. It will show all versions and tags on every file in the project.
Distibuting finished/stable code ( ex, exp, export )
You must have tagged the project. This so that all exports are repeatable. Change directory into your checked out project, and do this:
cvs exp -r tag_name -d dest_directory .
If you are in your sandbox, this will create a copy of the code in dest_directory/project_name/
I highly recommend that the dest_directory be outside of the sandbox.
This is usefull to do before using shar or tar to archive, turn in, or distrubute the code.
additional notes
CVSROOT
For all of the cvs tools you must provide a repository location. This can be done explicitly with "-d" flag, or it will use the environment variable CVSROOT. Note the -d flag is for cvs, not the cvs command, for example doing an init this way is :
cvs -d ~/cvsroot init
logfile symbols
All of the expanded symbols from RCS work in CVS.
Working in groups
One person needs to create a cvs repository, set the group on the directory, and make it accessable to the group. In this example my group is named testgroup and the users are jclark, mf000, and aa000. I put the repository in my home directory.
Everyone in the group will want to set these.
export CVSROOT=~jclark/cvsgroup newgrp testgroup umask 006
Create the repository, and get the permissions right. Set the group and the 2 in the chmod is the sticky bit, it says all new files in the directory belong to the same group as the directory, even if I forget the newgrp command to change it.
cvs init chgrp -R testgroup ~jclark/cvsgroup chmod 2770 ~jclark/cvsgroup
When you do your first checkout you will need to perform the two permission steps on that as well, or the files will only belong to the creator, not the group.
Resolving conflicts ( up, upd, update )
If you go to do a checkin and there is a conflict, it will abort the checkin, and tell you to update. From inside the sandbox run this :
cvs upd
It will update every file to the current version, and where there are conflicts, it will tell you. Now you need to edit the file and resolve the conflicts. They are in diff mode, showing yours and thiers, and you have to be blind not to find them. Once you have resolved the conflicts the code can be checked in ( unless someone beat you to it again ).