Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. 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)
  2. Schema source (a .sql file)
  3. Schema-based code generation

The 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.

share|improve this question
If the schema is versioned independently, how do you guarantee it matches the rest of the codebase? –  tdammers Oct 10 '12 at 5:35
@tdammers I don't, just on merges with the baseline I assert that it matches the codebase (I use a DVCS, so I laugh at branches and scary merges) –  dukeofgaming Oct 10 '12 at 8:53
I think Yam's comments are spot on. If you were intent on creating a model branch, then you should strongly consider adding a version tag within your DB. You can then use the version tag within your code to defensively program against the DB at that point in time. Keep in mind that this can create a lot of ugly code due to the if-version checks. –  GlenH7 Oct 10 '12 at 14:25
"With a model branch you wouldn't have to reconcile the schema model with binaries in other feature branches..." - but you have to reconcile for same binaries in multiple heads in single branch, because you can't block parallel development (and possible conflicts) –  Lazy Badger Oct 10 '12 at 23:21
add comment

3 Answers

up vote 6 down vote accepted

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?

  1. You create commit history that appears "out of the blue". It's hard to follow where it came from or why, after a while.
  2. 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.

share|improve this answer
Couldn't the "cohesive links" be the branch merges? –  dukeofgaming Oct 10 '12 at 8:54
Not "cohesive links", but "cohesive changes". It makes a difference because merging branches (incidentally not always an automatic procedure) requires you to already know which branches to merge (and sometimes the order). This means that until the merge, the cohesive links are only in the developers' minds, and that creates fragile environments. –  Yam Marcovic Oct 10 '12 at 10:16
I just edited my post to highlight some issues, have a look. –  Yam Marcovic Oct 10 '12 at 10:23
You are right, this might lead to even more conflicts. What I resolved to do is simply break off the model in modules –  dukeofgaming Oct 10 '12 at 19:19
add comment

I'd recommend to put all kinds of sourcecode together that builds up a running system (inlcuding database-queries and -schemas)

Why? Because, then you always have a relation between your code and the rest of the things that build your system (configuration, SQL, Readmes, Tests, ...). If you make a change, you get certainly reminded to change those other artifacts, too. If you have different branches, or even different repositories, it is much harder to remember which revision of branch A belongs to what revision of branch B, though leading to mistakes.

We used to work with release-branches, once. For that purpose, all developer agreed to a common procedure:

  1. fix a bug in the release-branch
  2. create a patch/diff
  3. apply the diff to the main branch

This is not very nice, because you duplicate changes that could have been merged. But it is an easy approach, every developer can handle, and SVN/CVS-merge sometimes is a pain in the a.

share|improve this answer
OH!, but here is the kicker... I don't use SVN/CVCS, I use Mercurial, so I laugh at long-lived branches and scary-looking merges –  dukeofgaming Oct 10 '12 at 8:55
I see, so your concern is the binary file that you can't merge on different feature branches. This, I think, is also the point you should work on. Using a branch, as suggested, is only a workaround and not the solution, IMO. –  Andy Oct 10 '12 at 13:49
Correct, you are probably right. –  dukeofgaming Oct 10 '12 at 19:15
add comment

It's bad idea in terms of "development philosophy" and usability

  • you have broken rule "branch per task/feature" - model branch have not related task (or more than one task in timespan)
  • This branch will be "forever-live" branch
  • additional permanent merges with features-branches and broken builds if merge missed after schema-changes
share|improve this answer
A model branch would just be a special development branch (which is also long lived) vs a production branch. Long-lived branches are not a problem for me. –  dukeofgaming Oct 10 '12 at 19:17
@dukeofgaming - I don't know and don't use "production branch" paradigm. "Branch per task" for me is small short-term sidetrack around default –  Lazy Badger Oct 10 '12 at 23:13
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.