Applies to
ApexSQL Source Control
Summary
When starting with ApexSQL Source Control, one of the questions is what is the difference between Native drivers and the CLI option.
You may wonder if there are there any advantages of Native drivers comparing to the CLI option when the same source control system is used, and if so, what they are:
This article describes advantages of using Native drivers comparing to the CLI option. As an example, Git is the source control system we’ll use through the article.
Description
Supported commands
CLI
Before looking at any other functionality, it is important to highlight that the CLI option supports the following commands only:
- Add
- Remove
- Commit
- Push
- Pull
Default settings for the above commands will be generated in the CLICommands.xml file. This file is automatically created in the add-in intermediary location when the user chooses the CLI option in the source control wizard. The following items are presented in the mentioned xml file:
| <ScSystem>git</ScSystem> | //Source control system |
| <ExecutableFile>Git.exe</ExecutableFile> | //Path to .exe file |
| <AddCommand>add $files$</AddCommand> | //Add files to be versioned |
| <RemoveCommand>rm $files$</RemoveCommand> | //Remove files from being versioned |
| <CommitCommand>commit -m “$message$”</CommitCommand> | //Commit files to source control |
| <PushCommand>push</PushCommand> | //Push files to the remote repository |
| <PullCommand>pull</PullCommand> | //Pull files from the remote repository |
Git is the pre-defined version control system along with the supported Git commands.
Native drivers
All of the supported commands previously explained for the CLI option are supported when using Native drivers. All other (additional) operations that can be performed when using Native drivers will be described below and as such, these are considered as an advantage of using Native drivers vs. CLI.
Linking a database to source control
CLI
When linking a database using the CLI option, a folder on a local machine (or a network drive) must be specified. It is mandatory that such a folder is previously initialized as a repository for the selected version control system, or it represents a cloned remote repository, in order to be used by the add-in. For example, if we use Git as an example, one of the following commands must be run from the command line, while the selected local folder path is set as current:
- $ git init
This one should be used in case there is no remote repository specified and a blank folder on a local machine (or a network drive) is a starting point
- $ git clone
This one should clone existing remote repository to a selected folder thus enabling the user to link a database on a local machine to the selected folder and use it as a repository
In any case, the selected folder will be used as a repository where all changes will be committed:
Native drivers
On other hand, when using Native drivers, there is no need to link to a local folder (although this is possible under the same conditions as for the CLI option). The user can link a database directly to the remote repository (as well as to pick a specific branch and to specify a folder inside the repository where a database will be linked) and commit/push changes directly to the remote repository without any further settings:
Working offline
CLI
The offline mode is not supported when using the CLI option. This means that if the selected folder (on a network drive or on a local file system) is unavailable for any reason, versioning of a SQL database will not be possible, until a new repository is used, or the connection with already selected folder is established again.
Native drivers
In addition to working with the remote repository, the Go offline option can be used. In case the remote repository is not available for any reason, the add-in informs the user that the repository is not available, but changes can be committed to a local folder, and later synchronized with the remote repository (when it becomes available):
There is no need to set this local folder, as it will be set upon linking a database. If there is a need, a location for the local repository can be changed from the add-in options.
Revision history
CLI
Reviewing the history of committed changes is not available in SQL Server Management Studio (SSMS) when using the CLI option. To achieve this, the user will have to use the version control client (either through the CLI or GUI). In case of using the CLI, a command (in this case for Git version control system) should be specified, in order to review the history of committed changes:
$ git log
Another option is to use GUI client to review the history of committed changes.
Reverting to any version of an on object from the version control history cannot be achieved using the CLI option, since such command is not supported. Similar to the process of reviewing the committed change sets history, the CLI command should be specified, outside SSMS, using the version control client.
Native drivers
When using Native drivers, a complete history of committed changes is available on a database level, as well as for any specific object:
In addition to this, comparing any version of an object with any other version of the same object from the history can be achieved inside SSMS within the same dialog. Directly from the Project history dialog, the user can visually compare between versions, and just by clicking the Get button, selected version of an object can be reverted from the history and applied against a database.
Version control labels (tags)
CLI
Working with labels or tags is not supported when using the CLI option. This means that a label cannot be either created, or already existing label cannot be applied, directly from SSMS. Again, a separate tool (3rd party client for the selected version control system) must be used, in order to create a label, or to apply any of the existing labels. Specifically, for Git, the following command should be used for creating a label called v 1.4:
$ git tag -a v1.4 -m ‘my version 1.4’
Native drivers
When working with Native drivers, tags (labels) can be easily created directly from SSMS, using the Create label context menu option:
This initiates the Label dialog where the name of a label and an optional description can be specified:
For applying any existing label, the Show labels context menu option is used:
Just by selecting the appropriate label from the list and clicking the Get button, specified label can be applied against a database:
Branching
CLI
Branching is not supported when using the CLI option. In order to create a branch a separate tool (version control client) must be used. For instance, Git branch, called testing, will be created with the following command:
$ git branch testing
In order to switch to the newly created branch, it has to be checked out, using the following command:
$ git checkout testing
From this point, any new commits will go to the testing branch. In addition to this, when there is a need to use another branch, that one needs to be checked out using the above mentioned Git command.
Native drivers
When using Native drivers, switching between branches can be easily achieved using the Branch drop-down list from the source control wizard. Branching at this point can be used if there is a need to link a database to a specific branch:
In addition to this, when a database is already linked, committing changes to any specific branch is available, as the branch where the changes is about to be committed can be selected from the Active branch drop-down list, in the Action center tab:
Working with multiple source control systems in parallel
CLI
Although this is not something that is used often, in case there is a need to work with multiple version control systems at the same time (for example having one database linked to Git, and another one to Team Foundation Server), it is important to mention that there is no way to use multiple version control systems at the same time, when the CLI option is selected. In that case, only one CLICommands.xml file is created with a pre-defined set of options that can be modified (customized), but for the selected version control system only. This means that in case there is a need for another version control system, the current version of the CLICommands.xml file must be removed from the intermediary location, in order to create (use) another one for the different version control system. Even if this is done, both files cannot be used at the same time, and switching from one to another can be a real pain.
Native drivers
Using Native drivers approach allows the user to link as many databases to any of the natively supported version control systems, without the need for any additional modifications. As an example, a couple of databases can be linked to Git, and another set of databases can be linked to Team Foundation Server. Just by switching the Action center tab between the linked databases, the user can continue to work with any of them, without changing any additional settings.
The following is a table that represents what options are supported when using the CLI option and native drivers:
| Add files | ||
| Remove files | ||
| Commit | ||
| Push | ||
| Pull | ||
| Linking to a local folder | ||
| Linking to remote repository | ||
| Working offline | ||
| Revision history | ||
| Get specific version | ||
| Labels (tags) | ||
| Branching | ||
| Using multiple version control systems at the same time |
