# \[ANN\] Branchable migrations -- A plugin to let you organize your migrations **URL:** \ **Category:** Rails\ **Created:** [April 3, 2008, 6:07am UTC](https://www.ruby-forum.com/t/ann-branchable-migrations-a-plugin-to-let-you-organize-your-migrations/133740 "2008-04-03T06:07:17Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Jeremy\_McAnally](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/c89c15/32.png) [@Jeremy\_McAnally](https://www.ruby-forum.com/u/Jeremy_McAnally)\ **Post date:** [April 3, 2008, 6:07am UTC](https://www.ruby-forum.com/t/ann-branchable-migrations-a-plugin-to-let-you-organize-your-migrations/133740/1 "2008-04-03T06:07:17Z")
I just put a new plugin named branchable\_migrations on Github. Branchable migrations lets you separate your migrations into “branches” (i.e., a director under db/migrate) that each have their own version. Using the forthcoming UTC timestamped migrations and this plugin, you can separate migrations by table or feature. Doing so should alleviate many of the problems that seem to pike up when working on teams and using migrations for everything. For example, if your db directory looked this: db/ migrate/ 001\_create\_things.rb 002\_create\_pandas.rb branch1/ 001\_create\_comments.rb 002\_create\_replies.rb branch2/ 001\_create\_posts.rb Then running rake db:migrate would look like this: * * * – Executing migrations in root… * * * # == 1 CreateThings: migrating # – create\_table(:things) → 0.0195s == 1 CreateThings: migrated (0.0199s) # == 2 CreatePandas: migrating # – create\_table(:pandas) → 0.0195s == 2 CreatePandas: migrated (0.0199s) * * * – Executing migrations in branch1… * * * # == 3 CreateComments: migrating # – create\_table(:comments) → 0.0032s == 3 CreateComments: migrated (0.0035s) # == 4 CreateReplies: migrating # – create\_table(:replies) → 0.0032s == 4 CreateReplies: migrated (0.0035s) * * * – Executing migrations in branch2… * * * # == 5 CreatePosts: migrating # – create\_table(:posts) → 0.0032s == 5 CreatePosts: migrated (0.0035s) And your schema\_info… version branch 1 branch2 2 branch1 2 root There are still a few bugs in the code to work out and a number of ugly spots, but it works. Suggestions, pull requests, patches, bugfixes, and complaints welcome. 🙂 –Jeremy – [http://jeremymcanally.com/](http://jeremymcanally.com/) [http://entp.com](http://entp.com) Read my books: Ruby in Practice ([Ruby in Practice](http://manning.com/mcanally/)) My free Ruby e-book ([http://humblelittlerubybook.com/](http://humblelittlerubybook.com/)) Or, my blogs: > **[Site not found · DreamHost](http://mrneighborly.com)** > > The owner of this domain has not yet uploaded their website. [http://rubyinpractice.com](http://rubyinpractice.com) ---
**Author:** ![Jeremy\_McAnally](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/c89c15/32.png) [@Jeremy\_McAnally](https://www.ruby-forum.com/u/Jeremy_McAnally)\ **Post date:** [April 3, 2008, 5:15pm UTC](https://www.ruby-forum.com/t/ann-branchable-migrations-a-plugin-to-let-you-organize-your-migrations/133740/2 "2008-04-03T17:15:31Z")
Jeremy - On 3-Apr-08, at 12:06 AM, Jeremy McAnally wrote: > Then running rake db:migrate would look like this: > nice thinking Jeremy. I wonder if this could be used to more easily coordinate developers (rather than IMing “I’m creating a migration #202!”). But I think for this use-case we’d want to run all 001’s, then all 002’s, etc. Or do you think your system could apply? Jodi ---
**Author:** ![Jeremy\_McAnally](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/c89c15/32.png) [@Jeremy\_McAnally](https://www.ruby-forum.com/u/Jeremy_McAnally)\ **Post date:** [April 3, 2008, 9:28pm UTC](https://www.ruby-forum.com/t/ann-branchable-migrations-a-plugin-to-let-you-organize-your-migrations/133740/3 "2008-04-03T21:28:50Z")
That wouldn’t be hard to hack in. Possibly like a “rake db:migrate SYNC=true” would run the same versions across all branches. What do you think? –Jeremy On Thu, Apr 3, 2008 at 11:13 AM, Jodi S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > own version. Using the forthcoming UTC timestamped migrations and > > branch1/ > > (rather than IMing “I’m creating a migration #202!”). > > But I think for this use-case we’d want to run all 001’s, then all > 002’s, etc. > > Or do you think your system could apply? > > Jodi > > > – [http://jeremymcanally.com/](http://jeremymcanally.com/) [http://entp.com](http://entp.com) Read my books: Ruby in Practice ([Ruby in Practice](http://manning.com/mcanally/)) My free Ruby e-book ([http://humblelittlerubybook.com/](http://humblelittlerubybook.com/)) Or, my blogs: > **[Site not found · DreamHost](http://mrneighborly.com)** > > The owner of this domain has not yet uploaded their website. [http://rubyinpractice.com](http://rubyinpractice.com) ---
**Author:** ![Jeremy\_McAnally](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/c89c15/32.png) [@Jeremy\_McAnally](https://www.ruby-forum.com/u/Jeremy_McAnally)\ **Post date:** [April 4, 2008, 3:25am UTC](https://www.ruby-forum.com/t/ann-branchable-migrations-a-plugin-to-let-you-organize-your-migrations/133740/4 "2008-04-04T03:25:56Z")
Jeremy - On 3-Apr-08, at 3:27 PM, Jeremy McAnally wrote: > > Jeremy - > > > > > so should alleviate many of the problems that seem to pike up when > > > 002\_create\_replies.rb > > > But I think for this use-case we’d want to run all 001’s, then all > > > 002’s, etc. > > > > Or do you think your system could apply? > > > > Jodi > > > > > Yes - that might work. (thinking out loud)I think it’s great as it makes migration collisions less likely - and team members we’d just then have to manage dependent migrations (ie. john’s migration 002, depends on bill’s migration 002) I like. And would use. Jodi