views:

215

answers:

1

I'm a one-man-band at the company I work for. I develop a Rails application for internal use within the company. Since the beginning of the project I have used SVN for source control and done most, but not all, development in trunk. Occasionally, when I have had very significant changes to make, I have branched and made the changes merging back in when done. All very typical.

However, none of those "significant changes" that I have had to make have ever touched the database migrations. They have always been view/controller stuff.

In this situation, with one development box, how do I play around with migrations and various database changes that I may or may not keep? I don't want to have to remember to revert all the migrations back to the beginning of the branch before I throw the branch out if it doesn't work.

I have considered setting up special development environments and databases (app_branch instead of app_development) but that seems to work strongly against the notion of "easy branching" that experimental development tends to rely on.

Are there best practices for this situation? What are others out there doing in this situation?

A: 

Well, if you want to have different schemas, you'll need multiple databases. "Easy branching" refers to source control, typically, and not databases. As far as I know there's no easy way to branch databases like you would branch in, say, git.

One thing we do to manage our dev/production branches is we check our current git branch in our database.yml file. If the current branch is production, we use one database, otherwise we use our dev database. something along the lines of this:

<% if 'git branch' =~ /^\* production/
    db = 'production_database'
   else
    db = 'development_database
end %>

development:
    database: <% db %>

Note, the 'production_database' refers to a local version of the production schema, not the live production database.

Doug R