[PATCH] Readable schema.rb timestamp

Revised to add a comment instead.

Revised to remove old, misleading commit message.

I know I suggested this approach, but I'm having second thoughts on how it's going to help anything. If you're merging the schema.rb, won't you be relating to the migration timestamps, which are in the compressed format anyway?

Could you explain a merge that would be easier to do after this?

If you pull from a branch, and it turns out there're three conflicts in schema.rb, how do you solve them?

What I do for all but the first conflict, is to look at the conflicts, and understand the other author's intentions.

But to solve that first conflict (define(:version => 'foo')), requires even less: you just pick the newest date. The problem is that many times they're a pain to tell apart. Or maybe it's just me:

20081016160846 vs. 20081015035216 (which is newer?)

I'm actually starting to disagree with the idea of schema.rb. Much like you, I'd like to not have the maintenance burden to keep migrations working forever, but... new migrations files (specially now with UTC timestamps) just merge cleanly across branches. It's hard to beat that.

So maybe for me the answer is to keep schema.rb out of version control, and from time to time, use the schema dumper to create a "rolled up" migration.

P.S: another alternative to this is to use Ruby's native support for underscores inside integer literals ... both on the filenames for migrations and on the literal passed to #define.

But why do you have conflicts in the first place? If everyone has run the same migrations, why would there be conflicts?

Oh. Because of the same reasons that numbered (non-UTC) migrations were a pain: different developers work on different migration files in their respective branches.

Bob forks master, and creates two migrations. Jane forks master, and creates one migration. Jane is done working, and pushes to master. Bob is done working, but before pushing to master, pulls from master. Boom. Jane's migration files merge cleanly, but her copy of schema.rb conflicts with Bob's.

On Oct 31, 2008, at 2:30 PM, Lighthouse wrote:

Damn, on the email, that reply had newlines:

• Bob forks master, and creates two migrations.
• Jane forks master, and creates one migration.
• Jane is done working, and pushes to master.
• Bob is done working, but before pushing to master, pulls from master.
• Boom. Jane's migration files merge cleanly, but her copy of schema.rb conflicts with Bob's.

There. Formatted. :)

I run into this conflict problem quite frequently too. It's really the only painful part left when working with migrations and branches.

However, I don't think making the "version" date cleaner is a good solution. It makes more sense that the version matches the migration number exactly. This also won't solve the core issue - there will still be conflicts over this date.

What purpose does this version number serve? With the new way of migrations it doesn't make as much sense because it doesn't tell the entire picture. You can still have missing migrations before this version which may or may not be represented in the schema.

Technically it should mention every version which has been migrated (like the schema_migrations table) but that isn't very practical here. Can we just remove it entirely?

That's a good point.

We only pass one version, and when rake db:schema:load runs, it assumes we've migrated all the way up to that. If it turns out that somehow schema.rb is missing one of the ones in the middle, then you'd have to find out which one, and run rake db:migrate:up VERSION="missing_foo" to force it.

If you get rid of the version, we'd have to assume that all have run, which means the possibility of the scenario described above increases a bit.

I guess the problem is deeper than I thought.

luxury watch

ff