This seems like it is very possible since just about every editor out there paid and free provides some option like this.

As others have said, onboarding an existing database with decades old sql script with really bad formatting makes the job so much more difficult. Especially with code history. Linking a database and being able to format the scripts (stored procedures) would turn this into a non-event.

The work around is to create the scripts, format them and then commit to source control. This is klunky and relies on manual adherence.

yep, really good idea

This feature would really help with code review. Our team all uses different styles in SQL prompt and this makes simple changes look dramatically different due to just the formatting.

Having an option to apply a default or a custom format prior to check in would be great!

It's such a shame that these Redgate tools have no awareness of each other. I would love it if SQL Source Control could automatically run a format on commit.

It would also be great if formatting rules could be commited to the repository so they only have to be set up once and then shared between all developers (like a gitignore file)

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.

This provides a great way to standardise code styles; trying to clean up a legacy database prior to adding it to Source Control could be a monumental task, but if the option were there to automatically apply the rules in SQL Prompt (which ideally would already be shared by the developers anyway) would mean the entire code base could easily be standardised.

It's 'one less thing to have to remember' too.

Say for example that View was created manually using formatted code (from SQL Prompt for instance) and checked in, the original version in Source Control is nicely formatted and so on. However, someone then comes along, makes a small change inside mssmsand hits save on the view, the code is mashed and FAR more lines are detected as being different when that revision is next checked in. When you script items for comparison to SVN, formatted versions should be compared. Obviously if you want to check in a layout change, there will need to be an option for that too.