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:)

SQL Source Control and SQL Prompt may not know about an environment (i.e. a developer not having access to staging or production server) and there's not really a facility in either tool to store information about the version of any environment.

Thus, SQL Source Control has to ensure backward and forward compatibility when creating migration scripts - which then triggers Code Analysis Errors in SQL Prompt...! It is a mess to clean up, and frankly a waste of time.

I suggest a feature where I can define my environments in the Tab Coloring in SQL Prompt including a listing of what version things are and then have this information shared around.

Another possibility is some "future shared utility" where it has useful information that it passes to each tool.

I've been told this is by design: When upgrading SQL Source control from say v5 to v6 all of the source control linked db configs are left behind in the previous AppData folder (%localAppData%\Red Gate\ SQL Source Control 5\ in my example) not moved to the new upgrade version folder (%localAppData%\Red Gate\ SQL Source Control 6\)

This leaves a history of folders in every users profile, and for us 'from the beginning' users I've got v3-v6 folders that I shouldn't need.

I'm told this is for Network and rollback reasons.

I suggest a checkbox or some such thing during the upgrade process to allow for moving of the link files and other necessary items, into the correct folder. If SC needs it, move it. You could even warn me and say 'these files are 15GB in size and may take some time to move, continue or leave it?'

When we look on the Commit tab at all the changes which have been made to our test environment, it would be useful to be able to see if objects are still being worked on (and who by). Could we have a column next to "Last changed by" to indicate the user who has the object locked?

For example, if one of our developers is still working on a given stored procedure, they don't want me nagging them to check it in if it is a part of a larger piece of work, which will all be checked in together later in the week.

Equally, I don't want one of our other devs to commit this work to Source Control inadvertently (especially when it's been picked up as a possible dependency in someone else's work).

NB: We're using the Shared database model, if that wasn't clear from the above!

It is very hard to do manual database link to repository/SVN if dealing with large number of databases (200 plus within one team) across large number of source control group. Every team member has to spend time and carefully map repository folder.

One user perform manual link to repository and his/her/ setting validated by QA Team before distributing link config file (xml) to the user group.

The basic requirement is user should be connected with the DB server and pass the repository path and credential. you may design few screen to navigate and collect user input based on provider input config file that was generated by another user.

By automating the process of Link and Unlink across the user group to avoid issues/error, saving time, maintain consistency and improve processes etc.

Let me know if your team need any help for designing this process.

Thanks!
Perwez

We have found that Source Control object locking can cause severe lag and even instability in SSMS for distant servers. The additional lag affects the SSMS Object Explorer contextual dialogs (right-click). Often the dialog will timeout and fail to render or multiple tries. Although we are able to disable object locking via the RedGate_SQLSourceControl_Engine_EngineOptions.xml file it would be much nicer to have control from the GUI. This could be in the form of a global on/off switch, or could even add functionality to blacklist certain servers. Alternatively, you could build in some kind of functionality to detect servers with high-latency and automatically turn off object locking.

Presently a standalone migration script runs before the main block. This seems odd as the point is to migrate data and for that you need schema to be in place.

I would like to be able to add standalone migration scripts to the end of the main block.

We ship databases with some data populated. (This is not simple static data that can be managed using linked tables). We ship for example some out the box entities such as Roles, A base User, a base Organization etc. They have circular references so to insert we have to turn off table constraints, add the data and re-enable. It would be great if we could add the script to do this to the end of the migration block rather than to an object at check in.

I propose you type Migration scripts:

1 Schema Migration - you have this whereby it is tied to say a table update
2. Pre Action Migration - executes before any main part of the checkout
3. Post Action Migration - executes after the main checkout block

The inability to do this is causing quite a bit of cussing on Forums.

Regards

Phil