I just thought it could be a good thing to have a dedicated version control branch for all database schema changes and I wanted to know if anyone else is doing the same and what have the results been.Say that you are working with:Schema model/documentation (some file where you model the database visually to generate the schema source, say MySQL Workbench, with a .mwb file, which is binary)Schema source (a .sql file)Schema-based code generationThe normal way we were working was with feature branches, so we would do changes to the model files (the database specific ones), and then have to regenerate points 2 and 3, dealing with the possible conflicts (or even code rewriting).Now say that your workflow goes the same way as the previous item numbering. With a model branch you wouldn't have to reconcile the schema model with binaries in other feature branches, or have to regenerate schema source and regenerate code (which might have human code on top of it).It makes so much sense to me it feels weird not having seen this earlier as a common practice.Edit: I'm counting on branch merges to be the assertions for the model matching the code. I use a DVCS, so I don't fear long-lived branches or scary-looking merges. I'm also doing feature branching.
Is a model branch a common practice?
dvcs;cvcs;scm
I would advise against it. Database schemata change together with other related code or resources. To be able to track changes properly, you need to make cohesive changes link to each other, and a shared commit is the best way to go about it.Consider your suggestion of keeping the schema under a separate branch. First off, you keep branches so you can push changes independently of other unrelated changes. What happens if you push schema commits without the corresponding code?You create commit history that appears out of the blue. It's hard to follow where it came from or why, after a while.If you only commit schema, remember that others can do it as well. That means that others can pull and then rewrite/change your schema changes and still pass all of their tests (because they're not testing your code). Then, when you want to commit your code you get conflicts, which may have otherwise been avoided.There may be other drawbacks, or even benefits. But these 2 right here are enough of a reason for me not to take this approach.Hope that helps.