Here's a CVS cheat sheet I prepared a few years back, it never made it onto the mailing list apparently, so I'm posting it here for "archival purposes". Note that CVS on sourceforge has undergone some changes in the last few years, so a few details may differ slightly, but more or less it should be accurate.
A few tips on using CVS, especially via http://sourceforge.net ============================================================== There is extensive documentation at sourceforge (under site docs) regarding both CVS and the use of sourceforge. Please make sure you go though this carefully before doing too much with cvs or sourceforge. Pay particular attention to sections F1 (CVS intro) and section G (info for project administrators). Also, you can check out "man cvs" for a good summary, and "info cvs" for all sorts of details. And this is a very nice online book that has lots of details: http://cvsbook.red-bean.com/ --------------------------------------------------------------------------- Misc setup issues.... Make sure that you have the following in your .personal (or .cshrc) file. If you don't your attempts to access sourceforge will hang: setenv CVS_RSH ssh if you don't want vi as your editor when using cvs : setenv CVSEDITOR /usr/local/bin/pico And if for some reason you are on a system without cvs, you can get it from... http://www.cvshome.org/ --------------------------------------------------------------------------- Once a source forge project is created, there is a cvs repository set up for the it under the name... /cvsroot/unix-project-name We have a number of such projects ... /cvsroot/ngram /cvsroot/wn-similarity /cvsroot/senseclusters /cvsroot/senserelate /cvsroot/umls-query /cvsroot/google-hack These directories are located remotely on a sourceforge site (cvs.sf.net). We must refer to them using our sourceforge user ids (anonymous access is also possible, but we won't mention that as yet). To access that directory via your user id, you do the following: cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/ngram ... Note that you must be registered as a developer of a project to access in this way. tpederse is a registered developer on the ngram project, so this is ok. If you are not a registered developer, you can do some cvs commands via anonymous access cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/ngram ... --------------------------------------------------------------------------- To import (initially create via upload) a CVS Repository, you must do the following: cd into the directory that you want to import, for example... cd nsp-v0.44 then issue the cvs command to import... cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/ngram import -m "initial import" NSP tpederse start This will take the contents of directory nsp-v0.44 and put them into the CVS repository of ngram at /cvsroot/ngram/NSP. --------------------------------------------------------------------------- Once you have code in a CVS directory, you or anyone else can check it out via the checkout command. This will make a copy of the repository in your home directory, and allow you to work on it. cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/ngram checkout NSP This will create a directory called NSP in the directory that you ran this from. This will be a copy of whatever is up at the sourceforge site in /cvsroot/ngram/NSP. If you look inside this directory, you will see that each subdirectory has a CVS file/directory in it. Don't mess what that. :) This is what CVS uses to keep your local version in synch with the master copy up at the sourceforge.net site. Once you have checked out the directory, then you can make changes to the files in the usual way. You can move files around, delete things, etc. You just have to remember to tell CVS what you are doing. So if you add a file (create a new file), you need to do a : cvs add filename.pl This will tell cvs that there is a new file that it needs to keep track of. Also, remember that if you create a file via an operation like cp you will also need to add the new file to make sure cvs knows about it. cp file1 file2 cvs add file2 Likewise, if you remove a file you need to tell cvs to forget about it: cvs remove filename.pl Remember that an operation like mv carries out a form of deletion, so you will need to do a cvs remove too... mv file1 file2 cvs remove file1 After these commands, and most others, cvs will ask you for your password before it actually acts on the command. Note that if you are making changes on files that already exist, then you can just make the changes as you wish. cvs won't know about these until you "commit" them, so you can modify, test, etc. and only affect your local copy of things. --------------------------------------------------------------------------- If you have had a working copy checked out for a few days, you can check with cvs to see if any changes have been made by other developers: cvs update filename.pl --------------------------------------------------------------------------- When you want to make your changes permanent, you need to commit them to cvs, using the following: cvs commit command. This will find all of your changes and upload them for you. You will be given an opportunity to add some comments for the cvs log, make sure you do that. Make sure you have the environment variable CVSEDITOR set to some editor that you like and know how to use. --------------------------------------------------------------------------- >From time to time we will want to release particular versions of software to post on our web site, make available via sourceforge on their file download site, etc. You should not simply package up a version that you have checked out, since that has all of the CVS directories/files inside, and that adds a certain clutter to things. So you can export the package such that it doesn't have any of the CVS stuff, and looks just like you had never used CVS at all. cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/ngram export -Dtomorrow NSP The -D flag is interesting. It tells cvs which version of the code you want. -D tomorrow means that you want all changes up to the present moment. If you specify today (also a valid option) you would not get any changes made since midnight. This will copy NSP from sourceforge into a directory named NSP that you can then rename, tar up, and start distributing. --------------------------------------------------------------------------- We will still want to create versions of our software, and release periodically. CVS supports this via the -tag operation. cvs -q tag V-0_09 This marks all of the files in the repository as being associated with version 0.09 (what V-0_09 means, note that tags can't have . in them!) Even after additional changes have been made (and committed) we can go back and retrieve this version. When we release a version, we will probably use the tag command in conjunction with the export operation, to create a distributed version. --------------------------------------------------------------------------- This is just a hint of what CVS can do, it's really quite powerful so please make sure you educate yourself as you start to use CVS. -- Ted Pedersen http://www.d.umn.edu/~tpederse
