Using private development sites
Although we maintain a primary checked out version of the source on wb-dev, it's confusing and dangerous to have multiple people editing the same checked out source. Testing of new libraries may also intermittently interrupt others work.
Private development environments help to avoid these conflicts. But with a site like WormBase that has large memory and hard disk requirements, maintaining a separate environment can be cumbersome. To alleviate these conflicts, all developers should establish their own private development space.
You can find your private site at:
Starting and stopping your site
Use the following command - you do not need to be root:
/usr/local/wormbase-devel/[username]/apachectl start /usr/local/wormbase-devel/[username]/apachectl stop
I've chosen the following arbitrary ports. Please let me know if there are conflicts:
Lincoln: http://brie3.cshl.org:9000/ Todd: http://brie3.cshl.org:9001/ Payan: http://brie3.cshl.org:9002/ Sheldon: http://brie3.cshl.org:9003/ Will: http://brie3.cshl.org:9004/
Note that these URLs are only valid from within the firewall. The following command will log you in to brie3 via ssh and tunnel to your port so that you can access it outside the firewall:
ssh -t -l [username] -L [yourport]:localhost:[yourport] brie3.cshl.org
You should now be able to browse your site at
Using the "development" site
These private sites change the nature of the main "development" site. I think we should consider this as a preview or testing site. I propose the following process:
1. Development and initial testing occurs within the private sites
2. Once complete, cvs commit changes
3. Check out your changes on main development site (brie3:/usr/local/wormbase) for community testing
4. To migrate changes to production nodes, check out changes in brie3:/usr/local/wormbase-production
1. All sites are checked out source from the CVS repository. You can commit changes as normal.
2. Please note that some files (elegans.pm, httpd.conf, perl.startup) require some modification to paths to get these sites to work. DO NOT CHECK IN CHANGES TO THESE FILES - they will break the live and development sites.
3. All sites use the same Acedb and GFF databases. *Please* contact me before tinkering with them as these are truly the staging databases used for updating the live site.
4. This setup launches minimal separate instances of the httpd. You might need to tweak some server parameters at wormbase-devel/[username]/httpd.conf but the starting values should be okay.
5. For those developing support libraries like BioPerl and Gbrowse, you will probably want to modify @INC either in httpd.conf, perl.startup, or your CGI, and then build your libraries in a private path using --PREFIX etc.
6. All logging occurs within your private directory in logs/
7. File permissions *should* be correct. Let me know if you notice something awry.
8. Not all features of the site are available (such as the mailing list archives)