shared model = always up to date - Not true

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace, andy.campbell.smith

shared model = always up to date - Not true

Postby allmhuran » Wed Oct 03, 2012 7:39 am

I know SQLSC doesn't "support" branching, but I'd like to demonstrate that it isn't actually even compatible with branching, which will also hopefully provide some clues into what it would need to do to support (or be compatible with) branching in an upcoming version.

Imagine a scenario with developers working in a branch. Before merging their own code into the trunk (a reverse integraiton) they first need to merge the trunk into their branch (a forward integration). This is standard practise.

Since we can't do that in SQL Source Control, let's say the merge is performed by the team leader using TFS.

Now, SQL Source Control asserts that if a shared development model is used, each developer's source is always up to date. But that's not true. I just merged changes into the source using TFS. No developer has these changes in their local script repository.

It is also the case that the changes are not as yet applied to the shared development database.. it is only the scripts folder that has been updated via the TFS merge.

Let's say I have all the developers in the team do a "get latest" after I do the merge, which they do this via TFS. Now their local scripts are up to date, but out of synch with the development database.

How do we synch things up? Perhaps after perfomring the merge, the team leader should right click on the development database in object explore and choose "set as target", then pick the latest version from source control as the source, and perform an update via SQL compare, and then do a check-in. It seems circular, but also necessary. An artefact of the fact that when doing database development, you are always developing against a "built" version of what is in source control. That is to say, your DDL statements are always operating against a real database, not just code in source control.

But even this workaround can't be executed. If I right click and choose "set as target", the radio button to select "source control" as the source is disabled. One can only drag in another actual database as the source.
allmhuran
 
Posts: 9
Joined: Mon Jul 11, 2011 2:15 am

Postby Brian Donahue » Mon Oct 08, 2012 10:35 am

When you set a database as a target, the "Source Control" option is available if the database is known to have been added to the repository using SQL Source Control. In other words, the three "Red Gate" extended properties need to be set on the database:
  • SQLSourceControl Database Revision
  • SQLSourceControl Scripts Location
  • SQLSourceControl Migration Scripts Location


These are created when you commit changes using SQL Source Control.

Regarding any suggestions for changes to the way Source Control works, you should have a look at the SQL Cource Control Uservoice site.
http://redgate.uservoice.com/forums/390 ... ce-control
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am


Return to SQL Source Control 3

Who is online

Users browsing this forum: No registered users and 1 guest