Some corner cases with DB Change Scripts

I have some questions regarding the usage of change scripts.

Let's say we have a project with two developers. Each has a local database, with a schema for development (with arbitrary data) and a schema for automated tests, which is filled and cleared by the test framework.
Further, we have three environments: Integration, where the project is built and the tests are run again; Staging, where the application is deployed and the DB contains some example data; and Production.

Now Developer 1 makes a change in the schema and commits updated code to into the trunk. She also creates a change script that can be applied to Staging (and later, Production).

Developer 2 was working on something unrelated and now merges the changes into his working copy. How will his development schema be updated?
After the change was already applied to staging, an emergency fix to the previous release was necessary. Lets say there is also a script to create the original database from scratch. Can BuildMaster be configured to automatically reset the database if its current version is "too recent"?

Hi Arian,

BuildMaster's Database Change Management follows the steps outlined in Database Changes Done Right: http://thedailywtf.com/Articles/Database-Changes-Done-Right.aspx

So, basically, each script is assoiciated with a release, and BuildMaster change script executer (action, manual, or self-contained executoer) can tell if the script has been run against a database by maintaining a metadata table.

You can use this to configure all sorts of patterns, including what (I think) you're refering to.

Alex