Our scheme is somewhat similar to jamie's, with directories full of
sequential patch scripts (organized by release instead of by date)
Rather than completely relying on scripts, we checkpoint and restore
the database. There are two relevant checkpoints: the last release
(for testing the upgrade scripts) and the current release, after the
upgrades have been applied, for the application devs. This works
*much* faster than rebuilding the databse, even though our db isnt
very large. We don't store the checkpoints in version control, they're
just on a shared disk.
We do let people go back and edit upgrade scripts. Mistakes can be
made, and sometimes this would be necessary anyway, if a script would
lose data.
We wrote a tool to apply our scripts in the correct order, rather than
rely on the naming scheme. There is an index file which lists the
scripts to apply for each release. The tool also records which scripts
have been applied in a version table, and prevents scripts from being
accidentally re-applied. This means that if (say) script 25 of 58
fails in a live situation, you can fix things up and re-run the
upgrade script safely. Having a flexible naming scheme for the patch
scripts is necessary or you'll end up with 3 people thinking they're
creating script07.sql at some point...
Every time I see this stuff though, I wonder why version control of
databases is *so* *hard*. Don't the DB vendors use version control
themselves?
-Baz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 15 23:00:38 2006