Hello. And welcome to another ApexSQL Source Control video presentation. In this video, we'll show how to link a database to a repository and perform some very basic operations, such as committing changes, getting the latest version of an object from the repository and applying it against a database, and reviewing the commit history.
The first step is to link a database to a repository. In order to do that, right-click a database in the Object Explorer pane and choose the "Link database to source control" command. This initiates the source control setup that will help in choosing the source control system development model as well as specifying database objects to be version-controlled.
ApexSQL Source Control supports some of the most popular source control systems, such as Git, TFS, Subversion, Mercurial, and Perforce. For the purpose of this video, a TFS repository will be used. After selecting the TFS from the list, we'll click the Next button to advance to the next step.
In the next tab, the Developments Model tab, we can choose between the dedicated and the shared development model in which the database will be linked to the source control repository. We will choose the dedicated development model and click the Next button.
The next step is the object filtering step, where the user can choose the SQL database objects that will be version-controlled. Objects can be filtered by schema or object type. In addition to this, by clicking the Show Objects button, any individual object can be excluded from being version-controlled just by unselecting the appropriate checkbox. For the purpose of this video, all objects will be included.
The final step of the source control setup requires the user to specify credentials for the repository as well as the URL of the repository. In addition, a database can be linked to the specified folder inside the repository using the Folder option.
In this video, TFS repository is hosted on Visual Studio Online. And a database will be linked to the StoresDB folder created inside the repository. After clicking the Finish button, ApexSQL Source Control scripts all previously selected objects, compares those objects with the repository, and shows the comparison result in the Action Center tab, which is the main communication channel between the local database and the repository.
The left side of the Action Center tab shows the current state in a database. And the right side shows the current state on the repository. Since a database is linked to an empty repository, the right side shows no objects at this point. By default, after linking a database on an empty repository, Apex Source Control will check all objects in the Action Center tab represented by the blue arrow. At any point, the action can be switched from Commit to Get just by clicking the blue arrow for the appropriate object. This means that the latest state of the selected object will be applied from the repository against a database. For now, we'll leave all objects to be initially committed to the repository.
Before committing, we'll provide a commit message and click the Apply button to perform the Commit operation. Clicking the Apply button will simply upload the selected objects to the repository. And ApexSQL Source Control will recompare a database with the repository. And if everything is properly committed, the message will appear showing that the database and the repository are synced.
From this point, your database is under Source Control. And any additional changes will be detected by the add-in and shown in the Action Center tab with a possibility to commit or roll back the specific change. Let's make some changes to demonstrate this.
Once the add-in detects changes, the message in the Action Center tab will be changed. After refreshing the Action Center tab, the list of changes will be shown. The exact changes will be available in the Script Differences View section. Let's commit one change in the same way we did for the initial commit. We'll select it, provide the comment, and press the Apply button. The second change is the one we don't want to commit. So we'll simply change the action and click the Apply button.
Each time the user wants to apply any change from the repository against a database, the "Get changes from the repository" form will be initiated, showing the exact list of action, along with the SQL script that will be executed against the database, and any warnings. The script can be reviewed, edited, or saved for later usage. For now, we just want to apply the latest change. So let's click the Apply button.
Let's check the history of committed changes. To do so, right-click the linked database in the Object Explorer and select the Project History option. This initiates the Project History form. In the upper left section, a list of committed change sets will be shown, along with the exact user who performed the commit, and a timestamp of the commit. Selecting any change set gives a list of objects committed in that change set. And selecting any object from the change set shows the version of an object from that change set in the bottom right section.
The user can choose any version of the selected object that will be compared with the previously selected version of an object. For instance, let's compare the version of the Sales.Customer table that we have recently changed between the initial commit and the current state in a database. To apply the version of the customer table from the selected change set-- in this case, the initial commit-- we'll click the Get button. The Apply Changes form that we previously explained will appear. So we can apply the selected change and close the Project History form. This way, any change made against the database can be easily committed to the repository or the current state in the database can be overridden with the latest version of an object from the repository or any other