Red Gate forums :: View topic - shared model = always up to date - Not true
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Source Control 3
SQL Source Control 3 forum

shared model = always up to date - Not true

Search in SQL Source Control 3 forum
Post new topic   Reply to topic
Jump to:  
Author Message
allmhuran



Joined: 11 Jul 2011
Posts: 9

PostPosted: Wed Oct 03, 2012 7:39 am    Post subject: shared model = always up to date - Not true Reply with quote

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.
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6577

PostPosted: Mon Oct 08, 2012 10:35 am    Post subject: Reply with quote

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/39019-sql-source-control
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group