Comments
Sort by recent activity
Put a timeout on your deploy process and treat this as an early warning that whatever change you just made might deserve special attention. Rebuilding a table and accidentally blowing away a clone is annoying, but relatively easy to fix. The main point is that it might one day save you from unexpectedly doing it on production. / comments
Put a timeout on your deploy process and treat this as an early warning that whatever change you just made might deserve special attention.Rebuilding a table and accidentally blowing away a clone i...
Whatever bits you are changing on disk will be saved on the clone differencing disk. Hence, expect table recreations on big tables to have a proportional affect on the size of the clone. If a table is bigger than the available harddrive space, don't expect it to work. However, as long as you are not doing table rebuilds etc it should work fine. And as long as you treat source control as god and your clone as a disposable playground for dev/test. you shouldn't need to worry too much about the occasional clone breaking. If it does, respawn and try again. As for the anonymisation - that should work fine. You can either use the pre-anonymised version to create your source image or, if you have either a Redgate Masking Set or a plain T-SQL script to anonymise the data, you can use the production database/backup (backup recommended obvs) and run your masking script as part of the image creation. Don't try to run data anonymisation scripts on your clones. If you are masking a large amount of data your clones will grow proportionally large. Run your masking scripts on the source database or during image creation. / comments
Whatever bits you are changing on disk will be saved on the clone differencing disk. Hence, expect table recreations on big tables to have a proportional affect on the size of the clone. If a table...
AppData\Local\Red Gate\SQL Source Control 7\LinkedDatabases.xml (Probably in C:\Users\Usrename\AppData) / comments
AppData\Local\Red Gate\SQL Source Control 7\LinkedDatabases.xml(Probably in C:\Users\Usrename\AppData)
https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility / comments
https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility
And this. More detail here: https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility / comments
And this. More detail here:https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility
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
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?
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
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...
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
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...
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
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.