This has been a big question mark on my mind.
I'm moving to Mercurial or Git very soon for my web software, and sometimes my branches require significant database changes which other branches should not see. This, I can't always share the same database for my branches.
Is there some standard way of dealing with database changes for branching and cloning? What do you all do? I'm using MySQL.
For handling cloning, your database should be designed to be multi-user.
For changes in schema, commit changes to the schema for that branch as part of the respository.
Then you have to make up your mind, for each schema, do you run multiple tablespaces in one database, multiple databases, etc.? Then commit a pointer to the correct one as part of the installation configuration in that branch.
I don't have an answer for you, but I did come across a recent article that might be relevant: Why your database version control strategy sucks and what to do about it, Part I
Using a database changset tool can be really helpful. I've used liquibase (http://www.liquibase.org), at work to manage version control for the db. I would warmly recommend that tool to anyone. Liquibase does support changesets, with configurable rollback scenarios. However, it is a tool for managing the schema, not the actual data. I wouldn't try to use it to keep the table data up-to-date.
However, I still feel that your best bet is to use liquibase, and have different schemas, for different source branches.
The database schema is itself (recorded in) a database whose structure is, more or less, defined by the INFORMATION_SCHEMA of the SQL standard.
Now, DBMS's are designed quite deliberately to allow only one single database value at any one single point in time. And since the catalog is itself "just a database value for the INFORMATION_SCHEMA database", SQL systems support, quite deliberately, only one single database structure at any one single point in time.