How to do SQL Source Control with TFS and WinMerge when you don'town "SQL Source Control"

I am a huge huge fan of Red Gate's SQL Source Control and use it every day at work. On my side projects though I can't necessarily justify the $400 price tag (yet). So in the mean time, I am using the following somewhat painful process to source control my scripts against TFS. (Microsoft now has a hosted "Team Foundation Service" where you can host your code for free.)

The current solution uses Visual Studio 2010, SQL Server 2008 R2 Express Management Studio, and WinMerge.

Here's the process:

Initial Load:

  1. In your TFS working folder, add a "DB" folder. For me this sits next to my Visual Studio Solution folder.

  2. Add the DB folder to Source Control.

  3. In SSMS, right-click on your database, choose Tasks > Generate Scripts and script out the entire database into your new DB folder. I create a file for each object.

  4. In Source Control, check all that in. You now have your database under version control, kinda.

  5. Add an additional sibling folder called DBCompare. Do NOT add this to Source Control.


Subsequent Check-In's:

  1. Delete contents of DBCompare if there are any.

  2. Re-script your database into DBCompare.

  3. Check out the entire DB folder from Source Control.

  4. Run a WinMerge compare between DBCompare and DB, ignoring DATE to see what REALLY changed. (Just looking at Date, it appears everything changed.)

  5. Use WinMerge to copy the changed files from DBCompare to DB.

  6. Check in the entire DB folder back into Source Control. TFS will only record "new history" on the files that changed.


There are a LOT of ways in which this process is inferior to just using SQL Source Control. Primarily there's no easy way to see what you're checking until after the fact (where you can look at the DB check-in history) b/c the WinMerge tool's file compare isn't working very well for me on SQL files. But this does at least accomplish the main goal of being able to see in TFS what changed over time.

Comments

  1. Update: Tip: If you'll use "ANSI" instead of "Unicode" during the Script generation, then the WinMerge compare will work better. (I'm sure WinMerge can compare Unicode files but I haven't cracked that nut yet, the results weren't intelligible.)

    ReplyDelete

Post a Comment

Popular posts from this blog

SQL 2005 SP4 and MSreplication_subscriptions

Hiding an ASPXGridView Delete button with HTMLRowCreated vs. CommandButtonInitialize

SQL Server Deadlocks - Easy Quick Start Guide