Bio perl subversion
From DrugPedia: A Wikipedia for Drug discovery
NOTE: BioPerl migrated to Subversion (SVN) in January 2008. The directions used here for SVN access may change over time.
This page describes how to use the Open Bioinformatics Foundation Subversion server and how to perform basic tasks in Subversion, including checking out the code, committing changes, checking out a branch, and merging changes between branches.
[edit] Bioperl SVN Repositories
| bioperl-live | Core modules including parsers and main objects |
| bioperl-run | Wrapper modules around key applications |
| bioperl-ext | Ext package has C extensions including alignment routines and link to staden IO library for sequence trace reads. |
| bioperl-network | Network package can be used to read and analyze protein-protein interaction networks |
| bioperl-pedigree | Pedigree package has objects for Pedigrees, Individuals, Markers, & Genotypes |
| bioperl-db | BioPerl DB is the Perl API that accesses the BioSQL schema |
| bioperl-gui | A GUI package which for Perl-Tk objects for a Graphical User Interface. Serves as the basis for Genquire |
| bioperl-microarray | Microarray package has preliminary objects for microarray data |
[edit] Following code updates
After you follow the directions below you'll see how to keep your local Subversion checkout up to date. How do you know when to do a Subversion update? Of course you can just do an update every time you start to work on code (or know there has been a bug fix). Subversion commit messages and diffs are posted to the bioperl-guts mailing list, and are available on the RSS feeds as well.
[edit] Instructions for downloading any BioPerl repository using anonymous SVN
- What you need to set up:
- Subversion on your local machine
- Once these are set up, use the following:
- Checkout the BioPerl core module, only (the right thing to do for most people):
$ svn co svn://code.open-bio.org/bioperl/bioperl-live/trunk bioperl-live
OR checkout a BioPerl package such as bioperl-db
$ svn co svn://code.open-bio.org/bioperl/bioperl-db/trunk bioperl-db
OR checkout all the BioPerl repositories with a repository alias
TO BE ADDED
- Tell perl where to find BioPerl (assuming you checked out the code in $HOME/src; set this in your .bash_profile, .profile, or .cshrc):
bash: $ export PERL5LIB="$HOME/src/bioperl-live:$PERL5LIB" tcsh: $ setenv PERL5LIB "$HOME/src/bioperl-live:$PERL5LIB"
This would override any other bioperl installation you may have.
- Test
$ perl -MBio::Perl -le 'print Bio::Perl->VERSION;'
To list the BioPerl code branches or tags use:
$ svn list svn://code.open-bio.org/bioperl/bioperl-live/branches $ svn list svn://code.open-bio.org/bioperl/bioperl-live/tags
If you wanted to check out the older 1.4 branch of BioPerl (called branch-1-4) into a directory called bioperl-branch-1.4 use the following:
$ svn co svn://code.open-bio.org/bioperl/bioperl-live/branches/branch-1.4 bioperl-branch-1.4
[edit] Checking out code from the repository with a developer account
If you have been given a developer account for read-write access to the repository it will be a login for the machine dev.open-bio.org. You will need
- Secure shell (ssh or ssh2) set up on your local machine
- svn set up on your local machine
- A local environment variable, SVN_RSH, set to ssh
Normally you will want to check out the trunk of a subdirectory (replace USERNAME with your dev.open-bio.org username):
% svn co svn+ssh://[email protected]/home/svn-repositories/bioperl/bioperl-live/trunk bioperl-live
The above checks out the MAIN trunk of bioperl-live (the core modules) into the 'bioperl-live' directory in the current working folder. Similarly, to check out bioperl-db:
% svn co svn+ssh://[email protected]/home/svn-repositories/bioperl/bioperl-db/trunk bioperl-db
Likewise, you can check out the entire repository like so (replace USERNAME with your dev.open-bio.org username):
% svn co svn+ssh://[email protected]/home/svn-repositories/bioperl
As you can see, the organization of the Subversion repository is a little bit different than the CVS repository. Each part of the repository has three subdirectories. For example, the bioperl-live part of the repository looks like this:
/bioperl-live/trunk /bioperl-live/branches /bioperl-live/tags
The trunk is the most current, bleeding-edge version. Most of the time, you will want to check out just the trunk as shown above. Unlike in CVS, under Subversion, branches and tags are just another directory, so creating a branch or a tag is essentially identical to creating any other directory. Branches and tags are covered in more detail below. Consequently, if you check out the entire repository, your working copy will contain a copy of every branch and tag and be enormous -- this is probably not what you want.
[edit] Changing your password
You will want to login into that machine via SSH and changed your password to only something you know. This is done by typing
% passwd
and following the instructions.
[edit] Setting up SSH keys
See Setting up SSH keys.
[edit] Removing the login banner
Often a login banner appears when during a login to the machine either directly or via SSH. To suppress this can be set at the client side. In ~/.subversion/config the following needs to be added (or just uncommented and edited slightly)
[tunnels] ssh = $SVN_SSH ssh -q
[edit] Checking in code
After you have made some changes to the code (and of course tested the changes by running the appropriate tests from the t directory), you will want to contribute them back to the code base. You were of course making your changes in the directory where you checked things out with your read-write account (i.e. your working copy). To commit changes you simply need to provide a commit message. If you have a lot of changes that are unrelated to each other it is better to commit things in a batch where the commit comment is relevant. Here is an example of checking in changes to a single file called Foo.pm.
svn commit -m "Changes to handle FooBar situation" Foo.pm
If I wanted to check in all the changes for a particular directory (FooMaker in this example) I could just cd to the directory and Subversion will figure out which files have changed and only commit those.
svn commit -m "Improvements to the interface API and assorted fixes related to testing FrozzBozz"
[edit] Adding new files
If you made changes that involved creation of new files you will need to first register them with Subversion. To do this you issue the svn add command like this. The ... indicates you could have listed several files at once.
svn add ModuleName.pm File2 ...
After you have added the files you can commit them to the repository (and provide an appropriate commit message).
svn commit -m "New module to do some FooMagic"
[edit] Conflicts
It is possible that since the time you started working on your code someone else might make changes and check them in before you do. That's okay, that is really the whole point of version control. Rather than locking a file so only a single person can work on a file, Subversion allows separate changes to happen and warns you when there is a conflict.
If the conflicting commits are for different parts of the file Subversion will merge the changes and no action will be needed by the user. Only if two (or more people) are working on the same part of a file will the user need to get into the file and merge the changes by hand. If you try and commit changes to a file after somone has updated the file in the repository, Subversion will notice this and warn you with the filename that is no longer up-to-date.
To explain this more concretely, lets assume we have a file called foo.pm with one line in it
Hello world
and two users who want to change the line to say: Bob:
Hello cruel world
Alice:
Hello there world
Bob checks in the changes so the repository has the version of the file according to Bob. Alice goes to check in her changes and gets a message from Subversion like this:
% svn commit -m "updating foo" svn: Commit failed (details follow): svn: Out of date: '/test/testfile' in transaction '59-1' Exit 1
If you get a conflict, you need to do one of three things:
- Merge the conflicted text “by hand” (by examining and editing the conflict markers within the file).
- Copy one of the temporary files on top of your working file.
- Run svn revert <filename> to throw away all of your local changes.
Once you've resolved the conflict, you need to let Subversion know by running svn resolved. This removes the three temporary files and Subversion no longer considers the file to be in a state of conflict.
% svn resolved foo.pm Resolved conflicted state of 'foo.pm'
And then you're ready to commit.
% svn commit -m "updating foo" Committed revision 59.
Finally, Bob will need to update his version (which can be done at any later time).
% svn update M foo.pm Updated to revision 59.
This is a good reason to make sure your version of the repository is up to date (by issuing the svn update) command before working on a particular file. Typically just go into your base bioperl directory and type svn update If you are finding that you are continually having conflicts it may be a good idea to contact the other user who is contributing code so you can coordinate your efforts. If you plan to embark on dramatic changes to a module it is also a good idea to post to the main Mailing list to let everyone know your intentions.
[edit] Branches
[edit] Making a branch
Sometimes when making changes, particularly those of an experimental or dramatic nature, it's a good idea to do so outside of the main trunk of the development tree. Such a parallel line of development is called (oddly enough) a branch. A branch is like having your own private copy of the trunk -- you can fiddle around to your heart's content without making the trunk unstable. And at the same time you retain all the advantages of keeping your changes under version control.
And in fact under subversion, a branch is literally a copy of the trunk. Here is how you create a branch:
[This assumes you're in the root of your working copy, something like ~/src/bioperl-live.]
% svn copy trunk branches/daves_branch % svn commit -m "Creating my own private Idaho."
[edit] Checking out a branch
In subversion, checking out a branch is no different than checking out the trunk, except you specify a path to the branch in the checkout URL. For example:
% svn co svn+ssh://[email protected]/home/svn-repositories/bioperl/bioperl-live/branches/daves_branch bioperl-live
[edit] Merging changes on branch and main trunk
Sometimes a bugfix or a code change needs to propagated to both the branch where it is being fixed and another branch like the main trunk. Rather than having to type in the changes twice you can use the Subversion merge capability to merge the changes over. If the changes are in conflict with other more recent changes to a file on the branch this can will require some manual editing, but otherwise merging changes can save you a lot of time.
Here is how to merge changes onto the main trunk assuming you have checked in some changes to a branch called BRANCH-1.1 and you are currently in a directory which is a checkout of the main trunk. Comments are in red are NOT to be typed in.
TO BE ADDED
Note that often you will get conflicts from a merge due to the $Id$ header which will have different values on the branch and trunk
- Note: This needs to be checked again to be sure that is right way to avoid the issue --jason stajich 14:18, 23 December 2005 (EST).
[edit] Packaging code for a release
See also Making a BioPerl release.
[edit] How BioPerl's Subversion repository is configured
This section describes how the OBF/BioPerl Subversion repository is set up.
- Draft svn auto-props list
[edit] External links
- CVS to SVN Crossover - a bottom-up learning curve for those familiar with CVS but not SVN.
