* Kevin Clark ([EMAIL PROTECTED]) [060220 14:54]: > The problem is the dependence tree. If you do it with timestamps, by > inserting your own migrations you may change things later migrations > depend on. Similarly, we lose the simplicity of VER#_description > because you wouldn't be able to use filesystem timestamps which would > break in a variety of cases.
The dependence tree is actually linear (hence one of the problems I was dragging on about :-), but your point is taken. If we were just talking code then the conflicts are the same as an SVN conflict resolution, which happens from time to time -- but we're not, the database is involved. With migrations one would have to back out the migration (i.e., rake migrate to a prior version) then sort out the problems, then migrate forward. Actually the more I think about it the more it really is like an SVN conflict merge. On your second point I think you're right that there's a pretty baby in the bathwater, being able to do rake migrate VERSION=n and having the file's named with the version numbers are both good features. I'm not necessarily recommending the adoption of an epoch timestamp version number instead of a natural number version, but I might toy with it at home if I can get a chance soon. Rick -- http://www.rickbradley.com MUPRN: 738 | and grab content, which random email haiku | you see happening in the | "window" to the right. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
