How do I resolve 580 Conflicts?
mlfossen
Posts: 2 New member
Is there a "select all" checkbox that works, so that I can select all and say "Use database version" to resolve all conflicts, so that I can avoid resolving conflicts one at a time for 580 conflicts?
Why are they called conflicts anyway? I know there is a difference between what is in Oracle and what is checked into TFS for each of these files. So I would reconcile those differences at the appropriate time by either doing a Get Latest or a Check In. I don't see that as a conflict, just a difference. I expect differences. That is why we bought the tool, to show the differences and let us reconcile by copying from source control to Oracle or vice versa.
Why are they called conflicts anyway? I know there is a difference between what is in Oracle and what is checked into TFS for each of these files. So I would reconcile those differences at the appropriate time by either doing a Get Latest or a Check In. I don't see that as a conflict, just a difference. I expect differences. That is why we bought the tool, to show the differences and let us reconcile by copying from source control to Oracle or vice versa.
Tagged:
Answers
I have bad news, there is not an option to select all in regards to conflict resolution. The 'Select all' check box is for selecting all objects either for Check-in or Get-Latest.
I suspect when the development team introduced this feature, they did not expect users to encounter hundreds of conflicts but one or two conflicts for investigation.
Would you please comment and vote using the link below on a Redgate UserVoice topic requesting a resolve all option:
https://redgate.uservoice.com/forums/174014-oracle-tools/suggestions/5350611-source-control-for-oracle-option-to-resolve-all-c
The Redgate User Voice forum is the best place to submit feature suggestions / enhancements.
Source Control for Oracle is not a tool for showing differences between data sources. It simply links an Oracle Schema or Schemas to a source control application's repository. In the background, when a refresh occurs or first starting up the tool, a 3 way comparison is taking place to identify objects for check-in to the repository, these appear on the Check-in tab. Objects to get from the repository which appear on the Get latest tab. If you have an object appearing on both tabs. it is considered by Source Control for Oracle to be in conflict and the user can select to take the version located in the schema or select the version in the repository to resolve the conflict.
If you simply just wish to know the differences, Schema Compare for Oracle is the tool you need to use, where you can compare the live schema to a check-out of the repository contents in a scripts folder. The comparison will generate a set of results where you can see the differences and deploy the changes in the direction required to make both data sources identical.
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
However, you mentioned that a 3-way compare is going on. Oracle is way 1, The repository is way 2, so... what would way 3 be? That is the "way" i have not been considering. I imagine that is a snapshot of a point in time when Oracle and the repository were in agreement, like for example, when the repository was created from Oracle by Source Control for Oracle? Where is that stored?
In the background, Source Control for Oracle uses the Schema Compare for Oracle engine to create and maintain folders of object creation scripts, called scripts folders, that represent the objects in your Oracle schema. When you make changes to your schema, you can commit them to source control. Likewise, when there are new changes to get from source control, you can apply them to your schema.
However, Source Control for Oracle doesn't just run comparisons between the database and the scripts folder in your source control system. This wouldn't capture all the information needed to track the changes. For example:
Amanda links a blank schema to a blank repository in her source control system. As part of the process, Source Control for Oracle creates a scripts folder in her repository, representing the (blank) database schema.
Amanda creates a table in her database and goes to the Check-in tab.
If we compare Amanda's schema and the scripts folder in source control, we can see a table in Amanda's database that isn't in source control. We don't have any information about where the difference came from, so we can't tell whether we should check-in that table to source control or drop it from Amanda's schema.
To solve this problem, Source Control for Oracle keeps track of three separate versions of the schema:
The schema itself, the current state of the schema in the Oracle database.
The transient, a local copy of the latest revision in source control. Source Control for Oracle periodically checks your source control system and updates the transient so it always reflects the latest version available (the head revision). The transient is stored in your local application data (C:\Users\<user name>\AppData\Local\Red Gate\Source Control for Oracle 4\).
The working base, a local copy of the schema at the last time you performed a check-in or a get latest. Like the transient, it's stored in your local application data.
The three-way comparison
When you first startup Source Control for Oracle or click Refresh or perform a successful Check-in / Get Latest, SQL Source Control runs three comparisons using the Schema Compare for Oracle engine. It uses the results of these three comparisons to create the list of changes.
1: Identifying changes for Check-in
Source Control for Oracle compares the schema and the working base. Changes you've made to the schema since the last time you performed a Check-in are listed on the check-in tab.
2: Identifying changes for Get Latest
Source Control compares the working base and the transient. Changes that someone else has checked-in to the source control repository in the period since the check-in or get latest with source control are listed as changes on the get latest tab.
3: Identifying conflicts and no-ops
When you first startup or refresh Source Control for Oracle runs comparisons 1 and 2 and checks the lists of changes against each other. If the same object appears in both lists, it means another user has checked-in a change to source control repository on an object.
At this point, one of two things may have happened: a conflict, or a no-op. To determine which, Source Control for Oracle runs a comparison between the transient and the database.
Possibility 1: you and someone else have changed the same object in different ways (conflict)
If the object isn't the same in the transient and the database, this change is a conflict. You can choose to resolve the conflict by applying the source control version to your schema ("Use source control version"), or overwrite the version in source control with your own version ("use database version").
Possibility 2: you and someone else have made the same change to the object (no-op)
If the object is identical in the transient and the database, it means you and another user have independently made the same change to an object. SQL Source Control doesn't notify you, because the two conflict resolution options ("Take theirs" and "Keep mine") are functionally identical. Instead, SQL Source Control silently updates the working base with the change. This is a no operation, or no-op. It's the only situation in which SQL Source Control doesn't list a change in the Check-in or Get latest tabs.
Many thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com