I use Sql Source Control in an unconventional way: I want to commit both sql scripts and code at once.  This means the CI server builds once with both sides.  This works very well if I can commit from Explorer using Tortoise.  It doesn’t work so well when I commit from inside Visual Studio or from inside Sql Management Studio via Sql Source Control.

Sql Source Control is basically Sql Compare between the database in Sql Server and something else, but built into Sql Management Studio – a very excellent workflow.  What’s really awesome: the “something else” (typically a source control system) could be anything.  They’ve built-in the ability to create my own command-line arguments for any source control system I have, then created the standard built-in configurations for the usual source control systems: TFS, SVN, Mercurial, and Git.  Well, what if my “source control command” was empty?  Now I’m scripting the database objects to the folder, and “committing” them to nothing.  Perfect.

They recently added the ability to specify where the working directory is, so I place it in my sql folder right next to my src directory.  Push “fake-commit” in Sql Source Control, then the real commit can happen with the related code from Tortoise.

It takes a bit of configuration, and I reached out to RedGate for clarity.  Here’s the steps they directed me to, now immortalized, to make “database to working folder” work:

1) When linking a db to source control, chose “More… custom setup.” on the left

2) Click on the “Manage Config Files…”

3) Make a copy of the Template.xml file in that folder and rename it to “WorkingFolder.xml”

4) Edit this xml file so that the name corresponds to the filename (WorkingFolder), so it appears correctly in the drop down

5) Save the WorkingFolder.xml file

6) Close and reopen the “Link to Source Control” dialog in SSMS

7) Choose “WorkingFolder” from the drop down and specify a working folder by browsing to where you want to write the .sql files to

8) Choose your model

9) Click link