Matt Connolly's Blog

my brain dumps here…

Monthly Archives: May 2011

Rails data backups, independent of database

With my continuing my interest in redmine / ChiliProject, I’m really wanting a way of backing up my data that is database independent. I did a bunch of searching around, and the best solution I found was here. However, it appears a little out dated, and didn’t work in Rails 2.3 for a few reasons:

  • There isn’t always a 1:1 mapping between tables and models. (Example: many-many relationships create extra tables).
  • The excluded tables list was outdated (probably from an earlier Rails)[1]

There were also some comments about the export being quite slow. This could have been because every record of every table was loaded up in an ActiveRecord model instance before being dumped to the YML files.

I addressed these issues and made a new version. Can’t attach a file to this blog, so it’s on pastie for now:¬†http://pastie.org/1877530

I’ve tested this getting data out of mysql and into sqlite3 and that works just fine. This is really handy for getting the data into a test environment quickly without having to set up more mysql databases, users, etc.

[1]: I’m testing this for Rails 2.3.11 as Redmine and ChiliProject are Rails 2.3.x apps.

If this saves you some time, or could be improved, please let me know.

Advertisements

Using git to move from redmine to chiliproject

I originally got onto Redmine because of its great out of the box support for git as well as remote subversion repositories. I’m keeping an eye on the “chiliproject” fork of “redmine” at the moment.

I have a redmine installation which includes a few custom modifications. So I have my “local” branch, which forked from redmine’s 1.1-stable some time ago, but when there’s a new version to do, I merge the new redmine version into my local, giving me, for example, redmine 1.1.3 + my changes.

So in order to evaluate chiliproject, and to see if my custom changes would go across, I figured I’d just add the chiliproject git remote and merge it across. Easy right? Well, kind of.

Simply doing this, didn’t work:

$ git remote add chiliproject git://github.com/chiliproject/chiliproject.git
$ git fetch chiliproject
$ git merge chiliproject/stable

This resulted in a *whole bunch* of merge conflicts; many of which actually looked to me like they should have been resolved automatically.

It appears those two repositories have a lot in common, but the main branches I’m interested in (redmine/1.1-stable and chiliproject/stable) have quite a distant common ancestor, which is what git will use to do the merge.

So, check this out:

$ # how many changes have I made from `redmine/1.1-stable`... out of curiosity?
$ git diff redmine/1.1-stable | wc
    3340   11917  126173
$ git branch chili-stable chiliproject/stable
$ git checkout chili-stable
$ git merge -s ours redmine/1.1-stable
$ git branch local_chili local_redmine
$ git checkout local_chili
$ git merge chili-stable
<--snip-->
$ # merge succeeded, how many changes do I now have from `chiliproject/stable`?
$ git diff chiliproject/stable | wc
    3340   11917  126173

And Voila! All of my changes since redmine/1.1-stable can be applied to chiliproject/stable without any conflict. So, when two git repositories are related by difficult to merge, let `git merge -s ours` come to the rescue!