How to resolve conflicts
A conflict arises when there’s a discrepancy between the latest version of an object in source control and the one in the local database. The most common reason for conflicts is that multiple people modified the same file simultaneously. dbForge Source Control helps resolve conflicts in the Source Control Manager.
Before you can use the Source Control Manager, you must link a database to the version control repository by following the steps outlined in the relevant how-to topic:
- Link a database to Git
- Link a database to a Git repository in GitHub
- Link a database to a Git repository in GitLab
- Link a database to a Git repository in BitBucket
- Link a database to a Git repository in Azure DevOps
- 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 Database Explorer:
The Source Control tool checks if any changes were made to the database, locally or remotely, and if these changes were committed to the repository. In the same way, it checks whether any changes were committed to the version control and whether these changes were deployed to the linked database.
In addition, the tool scans for conflicts that can occur when multiple developers make changes to the same file 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 the Source Control Manager can display 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 version-controlled using Source Control, and has not been committed to the remote repository yet. Selecting the object and clicking Undo will remove it from the local database.
- The Remove change type means that the object was deleted from the local database that is 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 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 you want to resolve.
Note
If you select the checkbox next to Conflicts, all conflicts will be selected.
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 | Type of the object |
| Name | Name of the object that will undergo changes. A <name> (Data) construction refers to static data |
| Owner | 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. The changes are then displayed in the Local changes section of the Source Control Manager and can be managed as described in Commit changes.
- Get Remote: Your changes will be discarded. The local database will be updated with the latest version of the object/data from source control. The changes are then displayed in the Remote changes section of the Source Control Manager and can be managed as described in Get the latest version.
Conflicts with static data
Keep in mind that data changes may not apply without the related schema changes. If you have applied schema and data changes to a database object, it is important to commit them together. Similarly, if you pull schema and data changes made by someone else, retrieve them simultaneously.
Therefore, if you have a schema conflict and a data change for an object, the change cannot be committed or retrieved without resolving the schema conflict beforehand.
Want to Find out More?
Overview
All features
Request a demo
