RedmineVersion » History » Version 8

« Previous - Version 8/9 (diff) - Next » - Current version
Chris Cannam, 2010-11-19 02:38 PM


Which version of Redmine?

Our Redmine installation is made from a version maintained in an Hg repository (see the Repository tab for this project).

This currently has two branches: default and yuya.

The default branch tracks Redmine trunk (we carry out an actual SVN checkout on top of the repo and commit the entire .svn tree).

The yuya branch contains the Redmine Mercurial overhaul patches from Yuya Nishihara described at Redmine issue 4455. This branch is the one that is actually used in the "production" site, and we merge to it from default each time we update default from trunk.

The aim is to track the Redmine trunk until Yuya's Mercurial overhaul patches are merged into trunk, and then to stop tracking the trunk at the next subsequent stable release.

How to update the Redmine trunk

Example: I start out doing some work in my test server, on the cannam branch. I want to update the version of Redmine that my branch is based on.

The way we track Redmine SVN is simple but gross. We simply have all the .svn directories checked in to Hg, so the whole thing is a working SVN repository. We use the default branch for tracking the upstream SVN -- this is its only function. Note in particular that we never, ever merge from Hg branches to the default branch. Arguably it should have a better name than default...

So. First, we clone a new copy of our repository. Why? Because there are some files in the live instance that we don't keep in Hg, for example copyrighted fonts and some scripts and config files with database passwords in them. What we want to do is update the SVN code and then use hg addremove to add to Hg anything that has appeared since we last updated. This won't work if we have additional untracked stuff in the directory as well, because all of it will be added too.

We'll clone our current copy rather than the master copy, because it's simpler -- then we just use the default target of hg push to push back to the current copy for checking, before we push back to the remote master.

/var/www/test-cannam$ cd
~$ hg clone /var/www/test-cannam work
~$ cd work

Now make sure we're on the right branch:

~/work$ hg update default

And update from trunk:

~/work$ svn update

Assuming that something actually changed, we can add and commit it:

~/work$ hg addremove
~/work$ hg commit

We now have the latest Redmine SVN trunk in our default branch. Push the changes back to our normal working tree (remember this is the default push location because we cloned from there) and clean up:

~/work$ hg push
~/work$ cd ..
~$ rm -rf work
~$ cd /var/www/test-cannam

Now, we want to merge this trunk code to our development branch. Check we're in the branch we want to merge to (i.e. our development one):

/var/www/test-cannam$ hg update cannam

And merge:

/var/www/test-cannam$ hg merge default

That merges all of the updates in the default branch to our own working copy. (The changes haven't been committed yet; we could still revert.)

And commit:

/var/www/test-cannam$ hg commit -m 'Merge SVN update from default branch'

To test this, we first need to run the Ruby on Rails database migration. RoR has a very nice system for maintaining database versions which allows it to update the database schema to match the current code regardless of which version you were previously using:

/var/www/test-cannam$ rake db:migrate

Since this is a development system, we should now be able to test the changes immediately by reloading the development site in the browser (pages are not cached).

Finally, we can push back to the master repo.

/var/www/test-cannam$ hg push https://code.soundsoftware.ac.uk/hg/soundsoftware-site