Comments
6 comments
-
Hi Kevin,
Thanks for the feedback. You'll be glad to know that this is exactly what we're working on now, and we expect to ship a new version of SQL Source Control that removes all of those additional processes (so no more RedGate.Cef.WebHost.exe or RedGate.AppHost.Client.exe instances) in the next week or two.
Hope that's good news :-)
Mike -
Yes, yes it IS good news!! Hopefully they don't get replaced with something else that is "good for the developers, but bad for users". :-D
-
We have just shipped a new version of SQL Source Control to the frequent update channel (5.8.3) that is using a lot let system resources. Please give it a go and let us know what you think. https://documentation.red-gate.com/display/SOC5/SQL+Source+Control+5.8+release+notes
-
I haz a sadz!!! I've been using Vault for umpteen years for umpteen clients' code control. So much for checking out the new version (at least until I get the time/inclination to migrate to another platform for SCC).
"The following version control systems are no longer supported:
Vault Standard or Vault Professional" -
I am sorry to hear that.
The best option for you (if you want to get all the improvements of the latest update) is to re-linking any databases currently linked to Vault using the Working Folder method and use Vault tools or command line to commit the changes.
More info can be found here: https://documentation.red-gate.com/display/SOC5/Changes+to+SourceGear+Vault+integration+in+SQL+Source+Control
-
Oooh - I think I can make that work! Thanks for the suggestion!
Add comment
Please sign in to leave a comment.
I have had two clients that have removed the product due to this issue. When I recommend this product now I caveat it with a disclaimer that running it on a machine with just 8GB of RAM (giving up that much RAM on even a 12 or 16GB machine is unacceptable IMHO) is problematic because it can consume 10% of the memory of the box before it even gets accessed to do "real work". I have no idea what it might go to in a complex environment where one regularly does source control activities.
Just for contrast, I still have a machine with an older (completely functional) version of Source Control installed on it, with several databases setup, which I use regularly. Actually DOING source control stuff in SSMS, using the SSC interface, etc. adds just 80MB of RAM usage to the SSMS process - and that is it since there are no other processes in play.
I know some of the details about the design choices that caused this issue, and they REALLY to be changed.