|
Some cvs hints for the impatientIt is envisaged that the direct use of the cvs repository to check out relevant versions of the code, to commit changes that have been tested and to tag versions for future releases, will be done by code managers at each site that is making use of and contributing to the trigger software. These hints are intended for the use of these managers. Essential cvs OperationsBefore you can do anything with cvs you have to tell it where the source repository is kept. You do this by setting the environment variable CVSROOT: setenv CVSROOT /afs/rl.ac.uk/atlas/groups/level1/cvshome/Repository (this is for csh; use the appropriate command for the shell you are using). The next thing to do is to check out a module. I have defined several modules while setting up the repository for the First Level Trigger software. Here are the relevant lines from the modules file in the CVSROOT directory in the Repository: CVSROOT CVSROOT The syntax here is module name followed by the directory it encompasses. The module names analysis, diag, daq[abc], daqclibs and prozaq include the entire tree for these projects. Let us assume that you want to work on the diagnostics software. You will start with the most recent version of the code (which is v203 as I write this), or an earlier version which you may wish to have for some reason. cd to the local directory where you will be working and then: cvs co -d v203_dev -r v203 diag This tells cvs that you want to check out the tagged version v203 module diag into a local directory v203_dev. You should now have the full v203 tree in your area. Note that if you leave out the "-r v203" then you will get the top revision (which is currently the same as v203 but will not always be so !). Devlopers working in a team would usually want to check out the top revision. You now make your modifications to any part of the module you have checked out, make the executable and test it. When you have completed your modifications you should commit these changes and tag the top revision if appropriate. Tagging a revision stamps it with a name so that you can always check out this particular state of the software at a later date. Under normal circumstances you should then release the module so that cvs knows you have finished working on it. Typical Session and frequently used cvs Commandscvs status (to check if your version is up to date) cvs update (to update your version with latest modifications others may have made since you did cvs co) cvs commit -m "comment on mods" files/directories (to commit the changes you have made). If you do not specify the comment then you enter the editor for a longer comment. cvs add file(s) (to add files which are new - cvs update tells you this also) cvs remove file(s) (to remove redundant files by sending them to the attic) cvs diff (to find out the difference between your local files and any given version in the repository) cvs tag tag_name (to mark all the top revisions of the current module as belonging to version tag_name) cvs history (to see repository access history) cvs log filename (to see all the revisions for the filename, plus any comments when commited) cvs import -m "comment on new stuff" path_to_cvsarea vendortag yourtag (to import new software tree from your current directory). I imported daqclibs by cd-ing to a directory where I had recently expanded the tar file and put it into the repository file DAQLibs/vRelease by issuing the command: cvs import -m "First CVS version v200" DAQLibs/vRelease start v200. This put the daqclibs software into the Repository directory DAQLibs/vRelease and tagged it as v200. You can see all the commands available by typing cvs help. Syntax for individual commands can be viewed by typing cvs -H command. There is extensive web documentation on cvs. |
This page was last updated on
16 December, 2013 |