When attempting to get latest changes and an error occurs, please be more detailed (e.g table, data, column, etc.) that caused the error that will allow user to correct the error. It is possible the user getting the latest change was the person responsible for the error, making it difficult to trouble shoot when your database is relatively large.

Make SQL Source Control external to SSMS like SQL Compare. This would allow the developer to use what ever IDE they want to and still commit the changes the same way. I would use SQL Compare to make changes, but it can't do everything SQL Source Control can. Mainly the migration scripts and the pre and post scripts.

When changing a data type used in a SP (e.g. add a new column to it and commit it). getting latest fails on other linked DBs. You have to drop the SP on the target DB.
The weird thing is that sometimes it works, but most of the times it doesn't. Not sure why the behavior is not the same all of the times...

Add support for manually merging changes in Visual Studio or VS Code instead of KDiff3 or Beyond Compare

When re-linking databases to source control, there is a warning message about loosing all uncommitted migration scripts, with only a OK/Cancel option. It's seems there should be an option for 'take me to the commit page' so that I can commit those scripts, then re-link.

Feature which should enforce user to lock the object before editing when administrator enables the restrictive policy for the users

If it is there it will be very much helpful for most of the development projects not testing and production.

Source conrtol should be a standalone app not SSMS addin. When performing get latest or commits, on large environments and slow connections this can easily take 20 minutes during which a click anywhere else in SSMS restarts the get latest/commit process. The logical use of source control being a SSMS addon has been outlived.

Currently, when comparing an SSDT project using SQL Compare, it only loads the base project. If the project references another project as the same database (the standard workaround to the circular reference problem), the objects in the referenced project will not be compared. This can lead to changes being missed and deployments failing.

It would be nice if SQL Compare could follow the reference back and include the objects from the referenced database in the compare as well.

I don't see why is good this product if it's posible do commit to an object that is locked. If the object is locked this means that the user is editing it Then why allow to commit to this object

We use a shared environment, and if someone forgets to check something in, then the changes made appear as if from the next user to edit the item.

Add an option/feature to actually parse the SQL ("Syntax aware") when comparing two different revisions, such that a change in just whitespace understands that the code is the same, even if the file(s) stored in SVN/other source control are different. Some people format things differently if they're not following standards in an org.

One "simple" way to do this would be the highly-voted option to use the SQL Prompt formatting engine to apply formatting to both revs and then see if there's a difference.

We are a shop that have multiple systems for clients that we managed from within a single database, using a separate Schema for each system.

I would like to be able to link a TFS database to a filtered list of objects (preferably) an entire schema but I could see where others might like just a subset of other objects.

If this is currently possible please let me know but I do not see a way to accomplish this without having a separate database for each system per client.

Add an option in the SSC filter to ignore differences in filegroup location as there might be multiple instances of a controlled database that have different filegroup configurations

I would like to see UltraCompare also supported as a Merge Tool.

Add Filter to Migration Scripts

When you go to create the migration script, you get to choose which commits are part of that script. It would be great to sort the migration script by the product descriptions or tags. When we have multiple commits to a database, and we might commit #project1 and #project 2 back and forth for a month, and instead of having to ctrl click through every other one, it would be great if we could group them together (or filter) and then generate the migration script easier.