Resolve conflicts
dbForge Source Control helps to resolve conflicts as a result of discrepancies between the latest version of an object/data in version control and in your local database.
The most common reason for conflicts is when several people simultaneously make different changes on the same objects/data.
The guide provides the following instructions:
- How to resolve a conflict in general
- Conflicts with static data
- Specific example of resolving a conflict
Before you can use the Source Control Manager, you must first link a database to the version control repository by following the steps outlined in the relevant how-to topic:
- Link a database to a Git repository in GitHub
- Link a database to a Git repository in Azure DevOps
- Link a database to a Git repository in BitBucket
- Link a database to a Git repository in GitLab
- Link a database to TFVC
- Link a database to SVN
- Link a database to Mercurial
- Link a database to Perforce
- Link a database to Plastic SCM and other systems
- Link a database to SourceGear Vault
The linked database gets the following icon in Object Explorer:
dbForge Source Control checks whether any changes were made to the database locally or remotely and whether these changes were committed to the repository. In the same way, dbForge Source Control checks whether any changes were committed to the version control and whether these changes were deployed to the linked database.
In addition, the tool checks for conflicts that can occur when multiple developers are making changes to the same file both in the repository and in the local database.
The Refresh progress window opens automatically, showing the stages of the refresh operation.
After the refresh operation is complete, the Source Control Manager opens displaying all the changes in the following sections:
It should be noted that Source Control Manager can display either all three sections, or two of them, or just one section.
Note
Local changes section
- The Add change type indicates that the object was created locally in the database that is being version-controlled using Source Control, and has not been committed to the remote repository yet. Selecting the object and clicking Undo will remove iit from the local database.
- The Remove change type means that the object was deleted from the local database that is being version-controlled using Source Control, but is still present in the remote repository. Selecting the object and clicking Undo will restore it in the local database.
- The Modify change type signifies that changes were made to the object in the local database that is being version-controlled using Source Control. As a result, the object’s DDL in the local database differs from the version stored in the remote repository. Selecting the object and clicking Undo will discard the changes made to the object in the local database, reverting it to the version from the repository.
Remote changes section
- The Add change type indicates that the object has been added to the remote repository since the last synchronization, and is not present in the local database that is linked to this repository via Source Control. Clicking Get Latest will add the object to the local database.
- The Remove change type means that the object has been removed from the remote repository since the last synchronization but is present in the local database that is linked to this repository via Source Control. Clicking Get Latest will remove the object from the local database.
- The Modify change type indicates that the object has been modified in the remote repository since the last synchronization. As a result, the object’s DDL in the repository differs from the version stored in the local database that is linked to this repository via Source Control. Clicking Get Latest will update the object in the local database to match the version from the repository.
If the database and version control repository are identical and no changes are found, the following window is displayed:
To resolve a conflict:
In the Conflicts section, select the checkboxes next to the conflicts that you want to resolve.
Note
If you select the checkbox next to Conflicts, all conflicts will be selected.
As you can see in the screenshot above, the Source Control grid contains the following columns:
| Column | Description |
|---|---|
| Change Type | Actions to be applied to the object or static data; in this case, the single available change type is Conflict |
| Type | The type of the object |
| Name | The name of the object that will undergo changes; a <name> (Data) construction refers to static data |
| Owner | The schema or database in which the object was created |
Select the required way to resolve your conflict:
- Get Local: Your version of the object/data will be committed to source control.
- Get Remote: Your changes will be discarded. The local database will be updated with the latest version of the object/data from source control.
When you click Get Local, the changes are then displayed in the Local changes section of the Source Control Manager.
When you click Get Remote, the changes are then displayed in the Remote changes section of the Source Control Manager.
After that, you can work with the changes from the Local changes section, as described in Commit changes, and with the changes from the Remote changes section, as described in Get the latest version.
Conflicts with static data
A conflict arises when multiple developers work on the same static data, such as reference or contact information. This happens when one developer makes changes locally, while another modifies data in the remote repository simultaneously. Therefore, a source control system cannot identify whose changes to apply and marks them as conflicts. As a result, these conflicts must be resolved before committing them to the repository or fetching the latest changes from the remote repository.
The bottom grid of the Source Control Manager for the Conflict section is divided into the following groups:
| Group | Description |
|---|---|
| All | All records of the table |
| Only in Database | Records that exist only in a database but are not stored or managed within the source control system |
| Different | Data that has differences, and where the conflict arises |
| Only in Version Control | Data that is present only in a version control system but does not exist in the local working directory |
| Identical | Data that has the same content or version both locally and remotely |
Note
Keep in mind that data changes may not apply without the related schema changes. If you have applied both schema and data changes to a database object, you need to commit them simultaneously. Similarly, if you are pulling someone else’s schema and data changes, pull them simultaneously.
Therefore, if you have a schema conflict and a data change on an object, the change cannot be committed or retrieved without resolving the schema conflict beforehand.
Let us demonstrate the conflicts and their resolution on an example.
Example
Let us showcase how to resolve conflicts using dbForge Source Control.
Suppose two sample databases - development and production are synchronized and contain the same tables: orders, customers, and products.
1. Link both databases to the same version control repository - development. After that, the Source Control Manager opens for each database, displaying the local changes, if any, or showing that the databases are identical.
2. Change the development database as follows:
- Remove the orders table.
- Add a column to the customers table.
- Add a column to the products table.
3. Switch to the Source Control Manager of the development database, select these changes, and click Commit to commit them to the development repository.
4. Change the production database by adding columns per table.
5. Refresh the Source Control Manager of the production database. Source Control detects the changes and displays them with the Conflict change type in the Conflicts section:
6. Select the customers table and click Get Local. The table is then displayed with the Modify change type in the Local changes section.
In the Local changes section, select the object, write the comment, and click Commit to commit the changes to the repository, or click Undo to discard the changes made to the object in the production database, reverting it to the version from the repository. The Commit progress window opens and shows the stages of the commit operation. When all the stages are complete, click OK to close the window.
7. In the Conflicts section, select the orders and products tables and click Get Remote.
The orders table is then displayed with the Remove change type and the products table with the Modify change type in the Remote changes section. Select the tables and click Get Latest to update the object in the production database to match the version from the repository. The Get Latest progress window opens, showing the stages of the operation. When all the stages are complete, click OK to close the progress window.
10. Refresh the Source Control Manager for the production database. To close the Refresh progress window, click OK to close the window.
The Source Control Manager shows no changes in the objects in the production database.
11. Switch to the Source Control Manager of the development database and refresh it. Source Control detects the changes and displays the customers table with the Modify change type in the Remote changes section. Select the table and click Get Latest to update the object in the development database to match the version from the repository.
After the refresh operation, the Source Control Manager will show no changes and determine databases as identical.
Want to Find out More?
Overview
All features
Request a demo
