Redmine

Johnny Goodman wrote:

1. Does Redmine support and/or recommend a specific application for MySQL version control?

Not that I know of...

Johnny Goodman wrote:

2. What is the best practice way to keep MySQL revisions associated with a feature you are working on in RedMine?

It is possible to create custom fields to store such info associated to that specific issue. Though I'm not sure if that will suffice the need specifically in terms of scalability...

Greetings Mischa,

Thanks for the reply. I'm a bit, well...baffled.

I thought about it and I can see C++ heavy projects like Ubuntu or native apps not caring too much about SQL schemas. However, for any and all Web 2.0 style projects that use RedMine to manage their work flow, I'd consider schema versioning essential.

We've rigged together a solution using SQLyog and some rigid process flows, but it is far less than ideal.

What do those in the trenches do - just change this info manually and hope for the best?

Johnny

Redmine is built on Rails and Rails uses a concept called migrations to manage it's database schemas. If you look in db/migrate you will find them. They are Ruby files that tell the database how to upgrade and downgrade it's schema.

Eric

Eric,

Thanks for the gentle answer to a less than stellar question. We are developing in PHP 5 + MySQL and I didn't consider the rails bend.

For anyone wishing to benefit from this embarrassing thread, here is a PHP5 DB migrations tool we are now looking into:

http://code.google.com/p/ruckusing/

There are other's available and I'll update this thread with a story on what we ended up doing and how it is working for us in the future.

Johnny

Well in case anyone is interested in my evaluation

• DbMastreo - Did not try. Not a big fan of pay options

• DeltaSQL - Large complicated setup requiring a server setup and client usage. Was painful and several days to finally get a decent basic setup in place. To complicated especially with a mind set of something simple like ActiveRecord.

• Liquibase - Very limited in capabilities plus requires making an xml version of your database structure. Also it might have been user error but we couldn't really figure out how to get it to work on a multitude of different databases (we have 4 different database types with several dev and qa instances for each type). Costly investment which eventually ended up in roadblocks because it didn't allow a way to do custom db specific sql at times as well. Learning a new format when everyone knows SQL already wasn't a good point either.

• Migrations - Lacking in documentation but was very quick and easy to get up and running and just worked. We are using that everywhere now. Uses SQL (with templating capabilities for flexibility) so no need to learn something new and easily migrates current schemas with no work. Only a little learning curve for us since we just mimiced the packaged examples and then just kind of emailed the author with questions about more complicated things. Otherwise the documentation seems to be intended more for people who have felt the pain that it solves. Has both a command line and a gui interface. Original intention was to just use the command line so we could script everything but turns out that we just use the GUI version all the time now cause it is just easier. Also has active development and a responsive author which made it more likeable as well.

My personal recommendation would be Migrations (http://migrations.sourceforge.net/)