We've got HUNDREDS of databases. Dozens in active development.
Several obvious details are missing from the initial setup of a linked database. These are specific to VSS, but I'm sure apply to other SSC versions:
1) Remember the last used (VSS) Database path.
2) Remember the last Source Control Folder, BUT... SUGGEST the name of the new DB as the terminal project name.
3) Add a Check box to "Auto Commit" ALL objects.

The amount of retyping (or even copy/paste/edit) the same information over and over is quite annoying.

Red Gate Source control should only need one workspace. Is there a specific reason Red Gate creates multiple workspaces per database linked? This is creating a mess of my workspaces.

Currently Source Control information is stored in database extended properties in the database being source controled. This requires Alter Database. In production those of us who use RedGate for Source Control, do NOT have Alter database because only the sys admins have that. And they do not want to bother with RedGate as they are just acting as auditors not database developers in production. Other environments we have full rights, just not production. It would be great to have an option to store the "Version", "Linked to" and "Migration folder" in a file not in Extended properties in the database.

Allow SQL Source Control to work on SSMS 2012, where SSMS 2008 and 2012 are both installed on the same machine

I am unable to link databases to TFS 2012 due to our parent company enforcing a Active Directory display name of "LastName, FirstName" which TFS claims is invalid due to the comma.

It is a known issue with TFS (http://connect.microsoft.com/VisualStudio/feedback/details/768112/tfs-2012-build-failing-with-tf10158-user-name-contains-unsupported-characters)

The workaround listed on Microsoft Connect is to use "domain\username" instead of display name when sending commands to TFS. Unfortunately, SQL Source Control doesn't expose a way to do this currently.

I don't think this suggestion is here already, apologies if it is! I would like to be able to link system databases (esp master) to source control as my company has a number of shared procs here. The ability to optionally exclude the normal system procs when extracting would be really useful.

TFS integrations really needs you to specify which workspace you are working with. This does wrong right from the start - when I try to link a database to TFS, it asks for the source URI and data folder, but it will only accept data folders already checked in, not that I have created in my workspace.

Please consider allowing, in a single action, the addition of ALL (or a selection of) databases in a server to the same base VSS location. This would require you to create new projects under the root for each DB and simply auto-commit the changes. Currently, Initial setup on servers with dozens of DBs is quite daunting.

This is actually a defect in the product. After upgrading to 3.1.0.5208 of the SQL Source Control, the Add-On for SQL Server 2008 R2 no longer loads. I had to revert to using 3.0.13.4214

SQL Source Control tab should NOT be the DEFAULT on SSMS startup, Object Explorer Details should be the tab selected.

I would like to be able to copy the Filters to different databases, or have a Filter template which I can save to apply to other databases. There are many objects which I do not want to be moved from Development, QA, Integration and Production. Currently, I generated the XML using a query with sys.databases and saved it to DifferenceFilters.xml which is a pain.

I had to uninstall RedGate SQL Toolbelt today, and this involved uninstalling 13 separate products individually. It would be nice if the easy installer could uninstall just as easily.

(So you aren't disappointed that I uninstalled: I was switching over to the MySQL tools.)

So, I install the tool to use with a real-world database of 1GB. And all I get are Out-of-Memory exceptions when trying to add data. Or even just run the tool. This is one of the worst software experiences that I've ever had!

Did I just get a buggy version? 3.0.13.4214

if computed column contains a 'hashbytes' function call, the hashbytes will be surrounded by [], like [hashbytes] which causes an error. this bug exists since version 1.1. why did fix that!

When adding a database to source control, all kinds of subfolders as created(data,assemblies,...) but these folder are not finegrained enough. for instance we do it by schema first then we use the same kind of subfolders.
So if we have a Import and Base schema, then in subversion we have the procedure/functions folder under Import and under Base.

It would be nice to be able to choose the folders themselves and also where to put a function and so on.. this gives more flexibility.

The source control folder field currently tabs upward to the question mark next to "Type or paste the URL.....". It seems that it should tab to entry 1 under "development model"

We have a partition scheme setup using a function

CREATE PARTITION SCHEME [partitionSchemeSystemId]
AS PARTITION [partitionFunctionSystemId]
TO ([PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY])

when SourceControl has populated SVN it has added an extra partition to the scheme

Sourcecontrol sees these as being the same between the DB used to populate SVN but when we link a new instance of the database to sourcecontrol it identifies a conflict

After installation, I was no longer able to load a project file within SSMS. I also was unable to create new projects. My fix was to reinstall SQL Server 2008 R2.