Changes between Initial Version and Version 1 of UsingCVS


Ignore:
Timestamp:
05/08/06 13:34:25 (12 years ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UsingCVS

    v1 v1  
     1In order to use CVS you have to 
     2 
     3 1. Have a valid account on the SIG Linux machines 
     4 2. Be a member of the group `cvs-user` (try the command `groups` to list the groups you are a member of) 
     5 
     6Contact  [wiki:JoshuaDF] if these conditions don't hold. 
     7 
     8You can view the SIG CVS repository on the web at http://sig.biostr.washington.edu/viewcvs/viewcvs.cgi/src/ 
     9 
     10== A Brief Introduction to CVS == 
     11 
     12For those not familiar with CVS, I'll attempt a brief introduction to the Concurrent Versions System. CVS is meant to be both a source code repository, and a system to manage (possibly) many people working on the same file(s) at once. The system works as follows: to start working on some code, you do a 'checkout', which will download a current copy of the code from the repository, and create a subdirectory (named 'CVS' within each directory to store status info, etc. When you have made changes to your copy of the code (this is called the "working repository"), and want to submit it back into the repository, you first run an 'update', which will make sure that no one has been working on the same part of the file(s) as you have been since the checkout. You will need to fix any conflicts arising from this situation that CVS can't fix on its own, but rest assured that this rarely happens (and when it does, it shouldn't have; this would imply poor or a lack of communication between people editing the files). Once past the update (which, again, is generally a painless operation), you are ready to 'commit' the files. 
     13 
     14Here's where the important part comes: While CVS will let you submit massive changes across many files at once, this is NOT the way it was designed to work. Unless all the files you have changed were changed for the same reason, don't commit them all at the same time!!! I cannot stress that any more. Doing so will allow us to easily track changes made to code (and, however unlikely, undo changes made). CVS will prompt you for a brief description of what you have done to the files you that are submitting, and you will want the statement to be true of all files, meaning that if you have three files that needed to be updated for the same reason, and you (so observantly!) found a typo in a fourth file that you fixed, commit the changes separately; that typo doesn't have anything to do with the changes you made in the first three files! 
     15 
     16== CVS within SIG == 
     17 
     18The SIG CVS repository holds all source code that has matured into a usable form in addition to the files for the SIG webpages. Generally when your code has become "stable" (a very relative, subjective term), you have ceased development on it and/or you are parting ways with the group, you will want to have your work imported into the CVS repository. You should, however, consider having your code imported as soon as it becomes relatively stable, as developing with CVS allows you to track your changes and essentially "undo" changes made in error (note that commiting files individually and in small increments is paramount in this role). 
     19 
     20== Actually Using CVS == 
     21 
     22Now, of course, you are eager to get started on working with CVS to make your life (and ours) easier. You will have several options for using CVS, depending on your platform and your familiarity with the command line. For Windows machines, we use TortoiseCVS, an entirely graphical interface to CVS using contextual menus (right-click menus) in the Windows Explorer. Read the  [wiki:UsingTortoiseCVS] page for the details. There is also "CVS for NT" for those wanting a command line. Other GUI programs, such as WinCVS and the likes are available, but TortoiseCVS should be sufficient for most CVS purposes and is by far the easiest and simplest to learn and use. 
     23 
     24== Setting Up CVS on Linux == 
     25 
     26For the Linux camp, there is, of course, the command line. Otherwise, we have [http://www.lincvs.org/ LinCVS] and Cervisia. [http://www.lincvs.org/ LinCVS] is probably more appropriate, as it is much more configurable. Since you are using Linux, you are probably going to just use the command line anyway (it's not that bad).  
     27 
     28These docs also assume you have the environment variables `CVSROOT` and `CVS_RSH` set appropriately. For most (ie, those using the bash shell), this can be done by adding these lines to the file .bashrc in your home directory: 
     29 
     30{{{ 
     31export CVSROOT=:ext:$USER@cvs.biostr.washington.edu:/usr/local/cvsroot 
     32export CVS_RSH=ssh 
     33}}} 
     34 
     35You will have to log out and back in to have the file be reread, or you can simply type the commands at the command prompt for the current session. 
     36To find out if these are already set type `env` or `echo $CVSROOT`. 
     37 
     38If you have chosen csh or tcsh as your default shell, you will instead have to add to .cshrc: 
     39{{{ 
     40    setenv CVSROOT cvs:/usr/local/cvsroot 
     41    setenv CVS_RSH ssh 
     42}}} 
     43Use `printenv` from the command line to see if it is set. 
     44 
     45== Import example == 
     46 
     47The first time you put something in CVS it's easier to do `cvs import` instead of  
     48adding each file. That command will upload all the files in 
     49the current directory, while `cvs add` just does one at a 
     50time. For `cvs import` you also have to give it a 
     51description, so, you could do: 
     52 
     53{{{ 
     54cd ~/directory/with/your/source/ 
     55cvs import -m "your message" src/projectname $USER firstimport 
     56}}} 
     57 
     58After this you should check the copy out so you get all 
     59the CVS metadata, and then work with it as any CVS tree: 
     60 
     61{{{ 
     62cd ~/someplace/ 
     63cvs checkout src/projectname 
     64}}}