RedmineVersion » History » Version 6

Chris Cannam, 2010-11-19 01:36 PM

1 2 Chris Cannam
h1. Which version of Redmine?
2 1 Chris Cannam
3 1 Chris Cannam
Our Redmine installation is made from a version maintained in an Hg repository (see "the Repository tab for this project":https://code.soundsoftware.ac.uk/projects/soundsoftware-site/repository).
4 1 Chris Cannam
5 1 Chris Cannam
This currently has two branches: @default@ and @yuya@.
6 1 Chris Cannam
7 1 Chris Cannam
The @default@ branch tracks Redmine trunk (we carry out an actual SVN checkout on top of the repo and commit the entire .svn tree).
8 1 Chris Cannam
9 1 Chris Cannam
The @yuya@ branch contains the Redmine Mercurial overhaul patches from Yuya Nishihara described at "Redmine issue 4455":http://www.redmine.org/issues/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.
10 1 Chris Cannam
11 1 Chris Cannam
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.
12 3 Chris Cannam
13 3 Chris Cannam
h2. How to update to Redmine trunk
14 3 Chris Cannam
15 4 Chris Cannam
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.
16 3 Chris Cannam
17 4 Chris Cannam
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@...
18 1 Chris Cannam
19 4 Chris Cannam
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.
20 1 Chris Cannam
21 5 Chris Cannam
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. 
22 1 Chris Cannam
23 5 Chris Cannam
@/var/www/test-cannam$ cd@
24 5 Chris Cannam
@~$ hg clone /var/www/test-cannam work@
25 5 Chris Cannam
@~$ cd work@
26 1 Chris Cannam
27 5 Chris Cannam
Now make sure we're on the right branch:
28 1 Chris Cannam
29 5 Chris Cannam
@~/work$ hg update default@
30 1 Chris Cannam
31 5 Chris Cannam
And update from trunk:
32 1 Chris Cannam
33 5 Chris Cannam
@~/work$ svn update@
34 5 Chris Cannam
35 5 Chris Cannam
Assuming that something actually changed, we can add and commit it:
36 5 Chris Cannam
37 5 Chris Cannam
@~/work$ hg addremove@
38 5 Chris Cannam
@~/work$ hg commit@
39 5 Chris Cannam
40 5 Chris Cannam
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:
41 5 Chris Cannam
42 5 Chris Cannam
@~/work$ hg push@
43 5 Chris Cannam
@~/work$ cd ..@
44 5 Chris Cannam
@~$ rm -rf work@
45 5 Chris Cannam
@~$ cd /var/www/test-cannam@
46 6 Chris Cannam
47 6 Chris 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):
48 6 Chris Cannam
49 6 Chris Cannam
@/var/www/test-cannam$ hg update cannam@
50 6 Chris Cannam
51 6 Chris Cannam
And merge:
52 6 Chris Cannam
53 6 Chris Cannam
@/var/www/test-cannam$ hg merge default@
54 6 Chris Cannam
55 6 Chris Cannam
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.)
56 6 Chris Cannam
57 6 Chris Cannam
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.
58 6 Chris Cannam
59 6 Chris Cannam
@