How can we help you today? How can we help you today?
AlexYates
Activity overview Badges (0) Posts (2) Comments (200)

Comments

Sort by recent activity
AppData\Local\Red Gate\SQL Source Control 7\LinkedDatabases.xml (Probably in C:\Users\Usrename\AppData) / comments
  1. Community
  2. SQL Source Control
  3. Where is the Instance\DB to local repo connection info stored?
AppData\Local\Red Gate\SQL Source Control 7\LinkedDatabases.xml(Probably in C:\Users\Usrename\AppData)
0 votes
https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility / comments
  1. Community
  2. SQL Source Control
  3. SQL Source control not functioning after most recent MSSSMS upgrade
https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility
0 votes
And this. More detail here: https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility / comments
  1. Community
  2. SQL Source Control
  3. Source Control and SQL Search - Not working after SSMS update
And this. More detail here:https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility
0 votes
I assume it's the same deal as this?: https://forum.red-gate.com/discussion/86733/red-gate-issues-with-ssms-18-5 Are you on the latest version? / comments
  1. Community
  2. SQL Source Control
  3. Source Control and SQL Search - Not working after SSMS update
I assume it's the same deal as this?:https://forum.red-gate.com/discussion/86733/red-gate-issues-with-ssms-18-5Are you on the latest version?
0 votes
There's a lot to unpack here. I'm going to try to avoid prescribing a process. Instead, here are some principles to think about: - Use git. But I think you know that already. You need the superior branching that comes with a DVCS. - Development, for the best part, happens on local DBs and goes into source control BEFORE it gets deployed to any shared environment. Work for different tasks that may need to be deployed independently should be committed to separate source control branches and merged with master when ready to be deployed. -  When source code is deployed to a shared environment, you take the ENTIRE BRANCH - you don't cherry pick. Your mental model should be based on developing and testing complete versions of code, to avoid wild west environments and "it works on my machine" problems. - You should avoid multiple long-lived branches, this creates awful merge pain. - You can generally make your life a lot easier by reducing concurrent pieces of work. One good way to do this is to think about Value Stream Mapping and focussing on reducing wait times throughout the process, and prioritising finishing (deploying to prod) current work over starting new work. -  Your source control strategy should mirror the reality of how you manage work, otherwise people won't be able to use it effectively. - Adhering to these principles are more important than maintaining your existing processes. I advise you read The DevOps Handbook. If you still want to talk this through, get in touch. I'm not sure a forum post will be enough to help you solve your underlying issues. / comments
  1. Community
  2. SQL Source Control
  3. Suggestions for how to use RG Source Control in our development path
There's a lot to unpack here. I'm going to try to avoid prescribing a process. Instead, here are some principles to think about:- Use git. But I think you know that already. You need the superior b...
0 votes
Hi Kean, I'm assuming you are using git, because you refered to "local repositories". If you aren't using git, please can you let me know. Centralised source control and distributed source control work very differently. I think you are overcomplicating things. The management of the individual developers' local repos should be up to the individual developers. They can put their local repos wherever they like. It shouldn't need to be centrally managed. It doesn't matter. As for the structure of the repo, perhaps it would be simpler to split this out into multiple repos? If I'm working on database 7 from server 3, why do I need to waste time and effort including database 2 from server 6? A git repo with between 200 and 600 databases in it sounds terrifying. How long is it going to take to clone the repo? All the branches for all them databases are going to create one hell of a spaghetti soup. In an ideal world, each database would be in it's own little repo. However, in tightly coupled systems, where sets of databases are littered with cross-database dependencies, it can be easier to treat them as a single component in a single repo. Even in this scenario, it would probably make life easier to split the 2-600 databases into groups of tightly coupled databases. Probably with a structure a bit like this: - Server1 - - Database1 - - - state << Link SQL Source Control to this directory - - - other_stuff (security scripts, test data, build/deployment scripts etc) - - Database2 - - - state - - - test_data - - - build_scripts - Server2 - - Database1 - - - state - - - test_data etc One final question: Are some of your databases the dev/test/prod versions of the same database? If so you should treat the dev/test/prod versions as a single database in source control. All your deployments, to all the databases in the pipeline, should come from source control. That way you enforce that dev/test/prod etc remain in sync with each other. / comments
  1. Community
  2. SQL Source Control
  3. Architecture of Repositories in Multi-User Dedicated Configurations
Hi Kean,I'm assuming you are using git, because you refered to "local repositories". If you aren't using git, please can you let me know. Centralised source control and distributed source control w...
0 votes
This sounds like a branching problem to me. Which source control system are you using? Git? TFVC? I'm going to assume git. Because git has sane branching that avoids copying files all over the place. If it was me, I would make your version the master version in git, and I'd create a branch for the forked version. You should now be able to flip between the master and the forked version with a simple git command and avoid needing to create a third directory for the ojects that are already in sync. If you combine this with auto deployment and provisioning capabilities (check out Redgate's SQL Proivision and the SQL Change Automation PowerShell cmdlets) your developers should be able to spin up databases in either the master or the forked version for dev/testing and deploy either version. You now have an awful merge task to perform. That's not easy, but 10 years of forked development will do that to you. The advantage with this approach is that you can gradually resolve your differences over time by updating either the master database and/or the forked database to achieve consistency one object at a time. Eventually, with enough effort, you should be able to fully merge the branches and bin off the fork. / comments
  1. Community
  2. SQL Compare
  3. How to work with forked databases
This sounds like a branching problem to me. Which source control system are you using? Git? TFVC?I'm going to assume git. Because git has sane branching that avoids copying files all over the place...
0 votes
Using the "working folder" option is exactly what I would have suggested. It has been designed for precicely this use case. The button is renamed from "commit" to "save changes" if you use this option. / comments
  1. Community
  2. SQL Source Control
  3. Source Control without the need to commit (outside of GIT)
Using the "working folder" option is exactly what I would have suggested. It has been designed for precicely this use case.The button is renamed from "commit" to "save changes" if you use this option.
0 votes
It's not available out of the box - but it could probably be automated using some sort of DDL triger and the SQL Compare command line. That said, any automated solution like that fills me with dread. It feels particularly painful to support/maintain. Much easier to get into the habbit of saving changes in SQL Source Control (using the "working folder" option) and then using the prefered git tool to manage commits/pushes etc. / comments
  1. Community
  2. SQL Source Control
  3. Source Control without the need to commit (outside of GIT)
It's not available out of the box - but it could probably be automated using some sort of DDL triger and the SQL Compare command line.That said, any automated solution like that fills me with dread...
0 votes
Yes / comments
  1. Community
  2. SQL Data Compare
  3. Using SQL Compare Deployment Scripts
Yes
0 votes
Total activity
354
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
152