Comments
Sort by recent activity
It will just update the files. It won't do the commit. Also, SQL Source Control does a lot of clever stuff behind the scenes that SQL Compare won't do for you: https://documentation.red-gate.com/soc7/reference-information/how-sql-source-control-works-behind-the-scenes / comments
It will just update the files. It won't do the commit.Also, SQL Source Control does a lot of clever stuff behind the scenes that SQL Compare won't do for you:https://documentation.red-gate.com/soc7...
Sorry - I neglected to follow replies to this thread and just spotted your responses. Glad you got it figured out. Good luck! / comments
Sorry - I neglected to follow replies to this thread and just spotted your responses. Glad you got it figured out. Good luck!
This is a git question rather than a SQL Source Control question. I've never done it before, but imagine starting somewhere like this would be your best bet: https://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/ / comments
This is a git question rather than a SQL Source Control question.I've never done it before, but imagine starting somewhere like this would be your best bet:https://gbayer.com/development/moving-fil...
SQL Source Control does not do this out of the box. Neither do other state based source control tools. SQL Change Automation (and other migration based tools) give you this as a side-effect of the deployment process, not solely for auditing purposes. Most people manage what version is deployed where in a separate tool. Something like Jenkins, Octopus Deploy or Azure DevOps Services. This is consistent with, for example, the way most people manage their application releases. It's unusual to update the application in some way just so you can see what's deployed. If you were desperate to achieve this in the database, you could add a post deploy script to your deployment process to (for example) squirt the upgrade script, a timestamp and the Octopus release number into an auditing table. This would provide similar functionality to what you get with an SCA project. Or you could use DLM Dashboard. 😉 / comments
SQL Source Control does not do this out of the box. Neither do other state based source control tools. SQL Change Automation (and other migration based tools) give you this as a side-effect of the ...
Makes sense. But you should get a CI server in place. ;-P / comments
Makes sense.But you should get a CI server in place. ;-P
That is not how SQL Source Control is designed to work. It sounds like what you want is DLM Dashboard? www.red-gate.com/products/dlm/dlm-dashboard Technically, there are things you can do. For example, you could write a script to run SQL Compare to sync a Dev database with a scripts folder and check those scripts into source control. Then you could run that script on a schedule or following a DDL trigger. However, I've not yet seen a scenario where that's been a wise choice. / comments
That is not how SQL Source Control is designed to work. It sounds like what you want is DLM Dashboard?www.red-gate.com/products/dlm/dlm-dashboardTechnically, there are things you can do. For exampl...
No probs. Good luck and happy deployments! / comments
No probs. Good luck and happy deployments!
+1 :-) / comments
+1 :-)
However, to answer your question more directly. Consider using a "release branch". For example, in Vincent's "GitFlow" model feature 1 and 2 would have been merged to develop. Then a release branch could be created and the testers would work on the release branch until they are happy to sign it off. Then they would merge it to master and deploy to production. Of course, you might prefer to develop your own strategy that does something similar. Or not. / comments
However, to answer your question more directly. Consider using a "release branch".For example, in Vincent's "GitFlow" model feature 1 and 2 would have been merged to develop. Then a release branch ...