How will your tool differ from something like DBDeploy, except for using XML?

Thanks for the great slides! We've been battling to get this right in our department for about 6 months now. We've got the code part down, but we're still doing database updates and rollbacks manually.

On a related note, I devised a simple DB-based system to deploy (and sync) only those rows that have been marked as 'approved'. If anyone is looking for a technique to do this, you can check it out at http://codecaine.co.za/blog/posts/quality-control-with-php-and-mysql/.

Glad you asked, Dave! I was looking into DbDeploy when I was looking for a tool to do what I needed. The two big things that DbDeploy is missing are:

1. support for stored procedures
2. support for multiple branches of development

We just have the stored procedures in particular directorys and use phing to add them to the database.

I've never really got my head round branching changes to the schema. Procedures, triggers and views I can appreciate changing between branches and using our simple directory full of procedure scripts, we can branch and manipulate successfully.

But how do you add a schema change to the branch, but not the trunk? And then eventually merge back into the trunk? The schema in the trunk could have changed several times in between and so on. I suppose it depends on how you run the branches. We tend to run maintenance branches and every now and then a feature branch.

I'm not trying to be pedantic, it's just something I've always struggled with. Maybe if I'd been lucky enough to get to your talk, things would be clearer :)