What is the standard or best way to combat database branching with Mercurial or Git branches?

Question

That was a big question in my opinion.

I will very soon switch to Mercurial or Git for my web software, and sometimes my branches require significant database changes that other branches should not see. This, I can’t always share the same database for my branches.

Is there a standard way to handle database changes for branching and cloning? What are you doing? I am using MySQL.

Answer 1

Using a database change tool can be really useful. I used Liquibase ( http://www.liquibase.org ) to work on version control for db. I would warmly recommend this tool to everyone. Liquibase maintains change lists, with custom rollback scripts. However, this is a schema management tool, not actual data. I would not use it to update table data.

However, I still find it best to use Liquibase and have different schemas for different source branches.

Answer 2

I have no answer for you, but I came across a recent article that may be relevant: Why does your database versioning strategy suck and what to do with it, part I

Answer 3

To handle cloning, your database must be designed as a multi-user.

For changes to the schema, make changes to the schema for this branch as part of the repository.

Then you have to decide, for each schema, do you start several table spaces in one database, several databases, etc.? Then copy the pointer to the correct one as part of the installation configuration in this thread.

Answer 4

The database schema itself is (written down) in a database whose structure is more or less defined in INFORMATION_SCHEMA of the SQL standard.

Now, DBMSs are designed deliberately enough to allow only one database value at any given time. And since the directory itself is "just the database value for the INFORMATION_SCHEMA database", SQL systems intentionally only support one database structure at a time.