Please note: This page is a work in progress.
The BioCatalogue codebase is:
Need to be installed on server / development environment
Embedded within codebase (no need to install)
Need to be installed only for development purposes
For future (do not install just yet)
, ONLY if you want to benchmark the Rails app.
Plugins (already in /vendor/plugins/)
Important Design Decisions
Tagging the SoapService object itself is not relevant, only tagging either the root (Service) or SoapOperation/Inputs/Outputs. Although, we now have cases where tags have been added to the SoapService object itself.
Pseudo-Synonyms for Search
Asset Packager (for CSS and JS)
We use a plugin called asset_packager to combine and compress the CSS and JS files to greatly improve the client side loading environment.
This plugin, in production mode, automatically generates two files:
… which are the combined and compressed versions.
This plugin relies on the YUI Compressor and thus requires a JVM environment to run in.
IMPORTANT: when doing at update to the servers, the following command MUST be run in order to refresh the packaged JS and CSS files:
Developing in Branches
Any major new features/development should be done in branches instead of trunk to ensure that trunk is always relatively stable. When development in the branch has reached a stable point then it can be merged back into trunk and deployed to the site. This way we can do updates to the beta site in a more managed fashion and make sure we get bug fixes into trunk asap.
For information on branching/merging in SVN:
All branches must be placed in /branches
Be careful about the configuration of database.yml for your branches - if the branch you will be working on requires major db schema changes then you might want to consider not reusing the db used for your trunk working copy (since if you have to then switch back to trunk to fix something you will be connecting to a db that is potentially inconsistent with trunk). Instead, create a new db for that branch and import the content from the existing db.
The recommended procedure:
Identify a discrete piece of work and create a branch in /branches for it (e.g.: /branches/read-users-minds).
Checkout your branch locally (ie: creating a new local copy of that branch).
Set up configuration etc as mentioned earlier in this page.
Write some code!
When you are happy that your branch is stable enough, to be merge the changeset into a local working copy of trunk. NOTE: at this stage, nothing has changed in trunk in the repository, just your local copy, so don't worry about conflicts etc.
Resolve any conflicts and fix any arising bugs.
Commit the changes you have made to trunk. In your commit message, make sure you explain which branch you have merged into trunk and from what revision (eg: if I created my branch in revision 2450 and then merged all changes from then till now into trunk I would say so in the commit message).
Pray to your divine saviour*
* Non-religious people are probably screwed here.
You can use either the svn command line tools or Eclipse (with the Subclipse plugin installed). Eclipse/Subclipse provides excellent merging and conflict resolution tools. For detailed instructions on how to merge back the changes in a branch to trunk check out: http://blog.daemon.com.au/go/blog-post/merging-with-subversion-and-eclipse.
Problems/Errors and Possible Solutions
Check if you have the file:
If not then copy:
gem update --system
sudo gem install bundler
bundle install --path path/to/where/gems/should/be/installed
If no path option is specified, bundler will install gems to your system default gems location