Project

General

Profile

Forums » Help »

Strategies for making an "upgradeable" redmine as painless as possible

Added by Enrique Garcia over 14 years ago

Some time ago I installed an (internal) redmine on my company's server (redmine 0.8.4 on ubuntu 0.8LTS with postgre). We basically downloaded the .tgz file.

It has been working ok, but we have decided to upgrade to redmine 1.0.

Upgrading the code is kind of complicated - I guess the best strategy would be to download a git or svn copy of the 1.0 branch, and make a directory diff.

But this is tedious - there must be a better way.

We've thought about making our redmine dependant on the git branch - so the code upgrade could be accomplished doing a git pull-like command.

This presents two problems:

  • If we install any plugins on vendor/plugins, how can we handle their directories?
  • We've also thought about adding some tasks (deployment with vlad, notably). We would have to handle those.

With these requirements, I'm guessing that the solution involves creating a personal git repo that "tracks" the official one, but has its own files, too. My experience with git is limited; I've only used it for github projects - I know how to change branches, but not much more.

Has anyone done something similar, or has any pointers in how to do it?


Replies (4)

RE: Strategies for making an "upgradeable" redmine as painless as possible - Added by Jacky Leung over 14 years ago

There probably no standard way of doing it. For me what I did is like this.

  • I folked redmine's git repository,
  • create a new branch divert from latest 1.0 stable.
  • Apply changes and commit the changes (e.g. plugins) with one big commit. (for me i have on commit with 10 plugins installation)
  • In case if I need to do upgrade say 1.1 in the future. i will create different branch on 1.1, cherry-pick this commit.

I suggest you make different commit for plugins installation and local file changes, so you can pick your commit you want by doing cherry-pick individually.

RE: Strategies for making an "upgradeable" redmine as painless as possible - Added by Felix Schäfer over 14 years ago

I have an svn checkout and up that from time to time, all changes I've done to it are only local though, so that solution might not float your boat.

I think getting a little deeper into git would be a good solution for you: you could add the plugins as "subrepositories" (darn, can't remember the exact name, but you get the idea) and could have several branches, say official that would mirror the official master branch, deployment for a the version you want deployed and devel for you to dabble with. The added bonus is that you could "upgrade" your deployment branch to the current head with "git merge official" which would (try to) merge all changes from the official branch since you forked into your branch.

RE: Strategies for making an "upgradeable" redmine as painless as possible - Added by James Bernard over 14 years ago

Using git is indeed probably the best way. I have simply forked redmine repository from github, then committed code changes, plugins and scripts into my clone and now each time I want to upgrade my redmine, I just need to make a git pull origin to get latest improvements from official redmine trunk, solving sometimes conflicts of course. I have a clear branch for deployment where I can easily merge upstream changes from official redmine and my local topic branches with a clear history.
Works like a charm :o)

RE: Strategies for making an "upgradeable" redmine as painless as possible - Added by Enrique Garcia over 14 years ago

Thanks all for the answers - I think I'll go with James' solution - using a local git repo with my own code changes, so I can do pulls.

    (1-4/4)