Index

• Requirements
• Making a local copy for the first time
• An example session
• Conflict resolution
• Common cvs commands
• Making a release
• Making a bug fix branch and a release

• An account on bio.perl.org, unless you are using anonymous CVS for read-only access
• secure shell (ssh) on your own machine (ssh homepage is at www.ssh.fi)
• cvs (cvs homepage is at www.sourcegear.com/CVS)
• setenv'd CVS_RSH to ssh

To start a cvs local copy from scratch, move to a clean area where you expect to see your working bioperl-live directories from, then go

prompt%cvs -d :ext:birney@bio.perl.org:/home/repository/bioperl checkout bioperl-live

This will build the bioperl-live tree for you from the CVS system with all the current .pm files in it.

To check out the html tree go

prompt%cvs -d :ext:birney@bio.perl.org:/home/repository/bioperl checkout html

prompt%cvs -d :ext:birney@bio.perl.org:/home/repository/bioperl checkout html/UserInfo

The checkout process produces a copy of the directory structure as real read/write files and an additional file in each directory called CVS. The CVS file contains the information about which cvs repository this directory comes from and which files in the directory are part of the repository (this way you can clutter you your local copy of the repository with temporary files and it is fine). You work in your local copy as if it was the root copy. Once you have made all the changes you want to make you go

cvs commit

• Wake up, get a cup of coffee, cd into your local copy of the cvs directory and type

  cvs update
  

  which brings your local copy up to date with the repository
• Browse around any of the files that have changed (by other people) that you are interested in
• Do your work on the local copy.
• Make sure the local copy is in a sensible state, ie, it at least compiles
• publish your changes by going

  cvs commit
  

• Drop a mail to perl-guts saying what you have done, and go to sleep ;)

• Work in the cvs local copy as your primary development area
• use cvs commit and cvs update often

Notice there is no concept of a lock in the cvs system. Freaky... but it works.

• The person to cvs commit first works fine
• The second person gets a conflict warning, and the file is shown in their local directory with

  >>>>>>>
      some stuff
  <<<<<<<
      other stuff
  <<<<<<<
  

  The regions in this file are the regions which are in conflict, and it is up to the second person to deal with it.

• The second person edits the file (locally) and cvs commits again, producing a clean copy.
• It is very polite for the second person to get in touch with the first person and explained what happened. People should double check the file in any case...

cvs ACTION

• cvs update - updates your local copy wrt to the repository (do this first thing when you get in)
• cvs commit - publish your local changes to the repository (do this last thing before you leave!)
• cvs status - see whether files have been changed locally or in the repository
• cvs add filename - add file to the repository
• cvs remove filename - remove a file from the repository

Making a Release

• Check it passes make test etc in your bioperl-live directory
• Double check everything
• tag the version you have in the bioperl-live directory by going

  cvs tag release-0-04-0
  

  Tags must be non whitespace characters and start with a letter
• cd outside of the bioperl directory
• Make a new export of the release using the tag

  cvs -d /home/repository/bioperl export -r release-0-04-0 -d bioperl-0.04 bioperl-live
  

  Notice here that
  • I used precisely the same tag in the release-0-04-0 as the tag. There is no semantics to the tag line. It just a ascii string that signifies something.
  • I used the -d option after export to make sure I exported into the bioperl-0.04 directory, not the bioperl-live directory, otherwise I will overwrite the bioperl-live directory...

• Now cd into bioperl-0.04 and type perl Makefile.PL, make, make test, (should pass!) and then make dist (make the distribution). Then - take the distribution somewhere else, untar it, go perl Makefile.PL, make, make test
• Post to guts/bioperl about the release.

Making a bug fix branch and a release

Say we want to make a bug fix to 0.04. Here is what we do:

• Either there is already a bug fix branch at 0.04 or you have to make one. If you are going to make one, it is probably best to post to guts first and ask people there if there is already one built. You can check out the symbolic tags by going cvs log README in the top level directory
  • To make a branch in the repository if noone else has for this release go

    cvs -d /home/repository/bioperl rtag -r release-0-04-0 -b release-0-04-bug bioperl-live
    

    This make a branch in the repository at the 0-04 level called release-0-04-bug
• move to a clean area and checkout the release-0-04-bug branch by going

  cvs -d /home/repository/bioperl checkout -r release-0-04-bug bioperl-live
  

• Now fix the bug, and then behave as in the standard making a release in this directory... so
  • Fix the bug, and check it works in this directory.
  • tag the release with a cvs tag release-0-04-1 or suchlike tag
  • Export a clean copy of the relaese using

    cvs -d /home/repository/bioperl export -r release-0-04-1 -d bioperl-0.04.1 bioperl-live
    

  • Check this works, tar it up and check it works somewhere else.

To see what tags a file already as in it go

cvs log README | more

cvs log README | more

This page is still under construction. In the meantime Ewan Birney birney@sanger.ac.uk is probably the one to address your CVS questions to.