Dedicated mode and Git
Piotr
Posts: 4
Just trying out SQL Source Control. Maybe someone can clarify the Dedicated mode for me. From what I read on http://www.red-gate.com/supportcenter/content/SQL_Source_Control/articles/SSC_Development_Models Dedicated mode should enable me to develop and make changes to a local copy of the database before I deploy them to the live version (if I understand it correctly). But this doesn't seem to be the case. I've linked a database and set it to Dedicated mode, so I indeed have copies of SQL scripts locally, but when in SQL Server Management Studio I modify a stored procedure, it gets updated straight in the database, and by committing changes I'm only updating my local repository... Maybe I'm doing it wrong (modifying procedure by editing ALTER PROCEDURE script and executing it) but otherwise does it mean I have to actually edit the SQL files in repository and then update database through 'Get Latest' panel? That means I'd have to force all my team mates to remember how to modify database (by editing local files), otherwise everyone will be committing someone's changes to their local copies = conflict when pushing to central repository. I'm pretty sure I'm doing something wrong but can anyone clarify the Dedicated workflow for me a bit?
Note that I'm using Git for source control, if that makes any difference.
Thanks in advance.
Note that I'm using Git for source control, if that makes any difference.
Thanks in advance.
Comments
SQL Source Control supports two development models. Simply put:
Dedicated=everyone works on their own individual SQL Server database, then commits the changes to source control. Changes and conflicts are handled by your versioning system
Shared=Everyone updates a single SQL Server database. Changes are audited by SQL Source Control.
At the time of commit SQL Source Control turns the database into a set of SQL scripts, and saves those to the working base.
For most source control systems like TFS and SVN, this also commits to the versioning system. For GIT, there needs to be a separate push to get the files to the server.
The whole idea of SQL Source Control as a product is that in either development model, changes are made directly to the database, then converted to script and submitted to a repository. Another approach would be the opposite and edit the script files and get the build system to create a database from those, but SQL Source Control does not work in that way.