Redgate’s SQL Source control is a great tool for commiting database changes to your repository, however it has one major drawback, it doesn’t allow you to commit any changes in the repository that are outside of the database, such as your web application or reporting framework.
This means that any breaking changes to the database would require two commits to your repository, one for the database change using SQL Source Control and the other for any corresponding application changes. This results in a commit that breaks the build – something nobody wants in their version history!
Fortunately, you have two options in this scenario. The first is to change SQL Source control to use “Working Folder” mode, where SCM integration is disregarded and SQL Source Control only generates files for you to manually commit outside of it’s environment. This gives you back full control of your commit, but means you loose any source control integration in the application and any advanced features (such as migration scripts for SVN users).
The second option available to you requires a bit more understanding of your SCM but preserves SCM integration in SQL Source Control. I’m a git user, so I will use that in my example. This method stages your non-SQL changes using your favorite git client and then commits them alongside the database, through the SQL Source Control interface.
- Stage your application changes using git add (or through your favorite UI)
git add .
Stage your application changes first using git add
- Open up SQL Source Control and add your database changes, write your commit message and remember to include details about your code changes (even though they do not show up in the change list below)
Open Redgate SQL Source Control and commit your database changes
- Hit commit and check your commit history (I’m using gitk in this example). You can see in my history that both files have been commited.
Review your commit history – here is a screenshot from gitk, showing a single commit with both a .cs and .sql file