This page walks you through trying out SQL Source Control. You won't need to set up your own source control system, or use real databases or repositories.
You'll go through the steps of:
This walkthrough all works on your local machine, but it's pretty much the same process when you're using a remote source control repository.
Instead of using your own source control repository, we'll link to an evaluation repository. This is a temporary Subversion repository created on your local machine.
Download this script.
It creates a test database, WidgetDev. We'll use WidgetDev as an example database.
In the Object Explorer, select WidgetDev.
Link the WidgetDev database to a SQL Source Control evaluation repository.
SQL Source Control opens as a tab when you open Management Studio.
If it's not open, you can open it from the menu bar:
In SQL Source Control, go to the Setup tab, select Just let me try it out, and click Next:
Select Create a new evaluation repository.
By default, its name will be the name of the database:
Now you've linked WidgetDev to a source control repository, you need to add the objects from the database to source control by committing them. To do this:
Great! WidgetDev is in source control.
If you and your team work on the same instance of a database, you can stop here. This is pretty much how you'll use SQL Source Control: just like this, everyone in the team will commit the changes they make.
However, if you use SQL Source Control to create a copy of the database for each developer, SQL Source Control becomes more powerful, as we'll see in step 3.
For this step, pretend you're another member of your database development team. We'll name him Alan.
As Alan, you'll use SQL Source Control to create your own copy of the database:
Select Use an existing evaluation repository.
From the dropdown menu, select WidgetDev and click Link.
Now there are two databases linked to the same repository.
You and Alan have both linked copies of WidgetDev to source control. Now, you can make schema changes and share them:
You can try it the other way around too:
This way of working is powerful, because you and Alan can make changes independently and simultaneously. You're free to develop complex changes that might cause other parts of the database or the application to break. Once you're happy with a change, you can commit it to source control and the rest of your team can get it when they're ready.
There are lots more SQL Source Control features you can experiment with:
If you make a change (but haven't committed it yet) and decide to undo it, you can revert the change. See Undo a change for instructions.
You can see the history of all changes that have been made, along with who made them, and their comment on the change.
At the moment, this won't be very interesting because you haven't made many changes, but you can take a look anyway. See View source control history.
If you have SQL Compare, you can go back to a previous revision in source control. For example, you could go back to that initial commit you made, before your and Alan's changes.
If there are objects in your database you don't want to source control - like roles - you can filter them out. See Exclude objects using filters.
If you have reference data that almost never changes, you could commit this to source control. But be aware - static data can slow down SQL Source Control's performance.
This example used an evaluation repository. This isn't great in the long run, because it only exists on your computer - so you can't share the repository with anyone.
You need to unlink from the evaluation repository, and link to your own source control system.