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.

  • git branch without history
  • Is there anything like branch/jump table in Java?
  • git rebase --onto results on single commit
  • Different default remote (tracking branch) for git pull and git push
  • Git rebase branch with merged children
  • How to correctly close a feature branch in Mercurial?
  • Is there some standard way of dealing with database changes for branching and cloning? What do you all do? I’m using MySQL.

  • How to un-commit last un-pushed git commit without losing the changes
  • Git pull from another users working directory
  • How to use git tfs with a team
  • Git search all diffs
  • What is the Sign Off feature in Git for?
  • Gerrit push not working. Remote rejected, prohibited by gerrit
  • 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.

    Git Baby is a git and github fan, let's start git clone.