What is the standard or best way to deal with database branching with Mercurial or Git branches?
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.
- SVN “missing revision” when moving to Mercurial
- Popularity of Git/Mercurial/Bazaar vs. which to recommend
- Using Mercurial (hg), can you just “hg backout” all the commits you did for the files you don't want to push, and then do a push?
- Subversion python bindings could not be loaded
- How do I relate an existing Mercurial and git repositories using hg-git?
- Which Distributed Source Control System has the best integration with Windows & Visual Studio?
Is there some standard way of dealing with database changes for branching and cloning? What do you all do? I’m using MySQL.
4 Solutions collect form web for “What is the standard or best way to deal with database branching with Mercurial or Git branches?”
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.
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
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.
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.