Stored Procedures under Source Control, best practice

There are tools out there, such as this from Redgate, but I have always found that best is to save as SQL files, perhaps even in a Database Project (SSDT?) in your solution.

Along with this, I suggest the following guidelines:

• Always assume the SVN version as the "current" / "latest"
• Ensure that every script you run has an appropriate "if exists then drop" at the start
• Remember to script your permissions, if any

You can initially create these SQL files by scripting directly from SSMS, and you can set SSMS to script all your "drop" and "create" as well as your permissions.

Saving the SQL files in source control provides control over the SQL files only. It doesn't control the changes of the actual database objects, nor it prevents simultaneous changes of the same database object by multiple users (and I guess you would like to have that under control, too). What we use is a 3rd party tool (ApexSQL Version), it integrates both with SSMS and VS, you can chose whether to work with a database version of the object, or with a Source Control version. If you're editing a database version, it's automatically checked out only to you, so no one else can edit it (it doesn't merge changes from different users). Only when you check it in again, others can modify it. And you can have your SC version different from the version of a live object (I use that when I leave for the day and plan to finish the edits and test it on the next)

Use RedGate Source Control to hook it up to your source control.

http://www.red-gate.com/products/sql-development/sql-source-control/

It will hook your SSMS directly to your source control repository and even allows for checking in static data.

Works like a charm