Are there local files stored for shared development

sdoran

We have been trying out the shared development model. Is this the basic setup? In shared there files stored on the source control server in the specified directory ONLY. Meaning there are NO files being stored locally on a users pc? So when a object is edited via ssms , there are no files being changed on the local pc. The script files only exist on the source control server and only get updated if the user performs a commit.[/b]

Brian Donahue

SQL Source Control always works from a "working base" folder, which is on everyone's local disk. It's not really possible to work directly from source control - most source control systems are designed to check out files to you locally so you can modify them and send them back up anyway.

We recommend using the "dedicated" model, meaning each developer has his own copy of the database to work with. In the shared model, everyone is working on the same SQL Server database and comparing that to their local working base. When you use the shared model, extra functions are enabled by SQL Source Control to show you who made changes. In dedicated, this would be tracked by the source control system because each developer is only ever going to commit their own changes; shared would imply a developer would be committing their own and everyone else's changes as well.

There is no need to edit scripts in SSMS when you use Red Gate SQL Source Control - the point is that everyone works on the database and Source Control does the work of scripting and committing the changed bits of the database to a source control platform.

This is quite a departure from Microsoft's solution, which works the opposite way in that you work with the scripts, and their database project will construct a database from those scripts.

sdoran

Hi. Thanks for your reply. I still have a couple questions. I appreciate your recommendation for us to use the dedicated environment, but we are a small shop and usually have only 2 people working a application db at a time and we are setup to operate using a shared model.

I am not clear on how the local working base files are used in the shared model. Here is an example scenario. DevA makes changes to TheAppDB and DevB makes changes to TheAppDB. DevA commits the changes. Sql source control will compare the TheAppDB on the server which has both developers changes and will update the source file scripts based on the changes. Is that correct? If so, what is the purpose of the working bases folder scripts? How are they used?

Second question - DevA makes changes to TheAppDB. Will DevB see a indicator that there are uncommited changes for the db?

Brian Donahue

Working bases are just scripts that source control created from the live database. It's pretty much the same as the "working folder" for source control (terminology probably varies between the dozens of source control systems out there, so check the source control system manual).

SQL Source Control continually polls for new objects and changes and when you go to the commit changes tab you see all of the changes it picked up. You can also look for the famous "blue blobs" that indicate an object has changed.