Introduce something similar to the "IGNORE" rules found in your Schema compare for Oracles solution to the SQL Server Source Control product.
The problem that exists for those of us with third party databases that have 10's of thousands of objects is that they are not workable using this product because it ONLY applies the filter AFTER it has already tried to extract and manage the ENTIRE database. The "IGNORE" option would allow us capabilities similar to filter but they would be applied UP FRONT and BEFORE the system ever tried to gather and manage every single object in the database. This is important because we actually only desire to ever manage the objects we are not ignoring or filter out. Without this capability the software crashes and runs for hours upon hours working hard on all of these objects that we DO NOT even want to ever manage.

This has been discussed by Redgate support, developers and product managers and I am hoping your votes will help to get this worked on ASAP as it is mandatory for success in our environment.

Currently, SQL Source Control and SQL Compare have an option to "Ignore tSQLt framework and tests". We want to create our tests in dev and include them in our stage deployments for regression testing. The current setting ignores the framework AND our custom test code.

We want the Red Gate tools to ignore only the framework, but not the custom tests. We will manage the framework install separately. Ideally, there would be separate ignore checkbox rule options, one for the framework and another for our tests.

We have to set the current option to unchecked ("don't ignore") and then set custom filter rules to have only the framework ignored.

It would help if we didn't have to add custom filter rules to ignore the framework and track the tests.

While it is great the SSC supports Git, I have found that when connected to a large repository, SSC can take forever to commit or do a get latest.

I have also noticed that the working base and transient folders can grow quite large as the whole Git repo is cloned into these folders. I have had to periodically go in there and have Git compress it's objects so that I can reclaim some disk space.

I imagine that the performance of SSC is related to the size of the Git repo and I just feel like there is room for improvement in how SSC uses it's Git repos that could increase performance.

Right now the SOC pane is linked to the database in Object Explorer. The problem in this is that the pane can't work asynchonously to get changes while I move on.

Give the slow performance of looking for changes and populating the commit tab, can we

1. Put a drop down in the SOC pane to choose the db
2. Have the Commit popular process (refresh) be set to work with this database asynchronously. Either allow me to set a polling interval or click the refresh button, but then allow me to move to another tab and continue to work.
3. Same for Get Latest

In both cases, I should be able to commit or apply changes and switch to antoher tab to work.

Currently accessing the log of the version control system is very slow.
On a good computer it takes me 20 seconds to open the view history from your menu.

To open the same log through tortoise svn it takes me 2 seconds to lokate the ex. "Open working base" under the "Under the hood menu" in Setup and 1 second to launch the tortoise SVN log viewer for the project.

Could you please consider adding a possibility to either open the history quicker, or alternatively allowing the user to open the version control log in an external viewer.

Maybe there is something that I don't understand here, but I don't see any reason why it should take such along time to open the log..

I really enjoy your products otherwise:)