Common Merge Conflicts

Best practices for resolving the most common project merge conflicts.

Overview

Merge conflicts generally arise when two users have made overlapping changes to the same object or if one user deleted an object while another user was modifying it. When conflicting changes occur, you must select which change to keep. For more information, see Merge Project Changes. This topic describes some of the merge conflicts you'll likely come across when working in the solution and best practices on how to solve these issues.

Data version config

Reason for conflict

If your project contains changes to data design, you’ll likely need a data version generated from the new logic specific to your project. This allows you to preview and surface your changes for validation. Once a data version is ready for preview, you will need to select a data version by hard coding it or using the autoload latest data version option based on your project. Because the data version applies to all projects, you'll often encounter a merge conflict when another project is published.

Best practices

• If the data versions for both projects are hard coded, you can choose either data version because you'll need to regenerate the data version.
• If the data versions for both projects are autoloaded and based on the current project, keep the data version configuration for your project and generate a new data version.

After you resolve this conflict, contact Visier Technical Support to help you generate a new data version and validate the changes.

Analytic objects

Reason for conflict

This conflict occurs when the same analytic object is being modified in two projects and one of the projects gets published before the other. This type of conflict usually arises when changes are being made to Detailed View and Guidebook. For example, there are two projects being worked on at the same time. In Project 1, property A and property B are added to Detailed View for the Employee subject. In Project 2, property C and property D are added to Detailed View for the Employee subject. If Project 1 is published first, you'll need to merge the changes in Project 1 with Project 2. Then you'll have to add properties C and D to Project 2 again.

Best practices

We recommend that you keep the changes from the tenant version and redo the changes in the project because the changes in the tenant version have been validated and released to production.

View Details

Reason for conflict

This conflict occurs when changes have been made to the Detailed View visual in two projects. Changes include:

• Adding or removing properties
• Reordering the properties

Best Practices

We recommend that you keep the changes from the tenant version and redo the changes in the project because the changes in the tenant version have been validated and released to production. This will also prevent you from accidentally removing properties that are already in production. If you have made a significant amount of changes and don't want to redo the work, contact Visier Technical Support for guidance.

Guidebook

Reason for conflict

This conflict occurs when the same Guidebook is being modified in two projects. Changes include:

• Adding new analyses or topics to the Guidebook
• Modifying existing analyses or topics that are used in the Guidebook

Best Practices

We recommend that you keep the changes from the tenant version and redo the changes in the project because the changes in the tenant version have been validated and released to production. We recommend that changes to Guidebook are done within a singular project. If you're going to make changes to Guidebook in multiple projects, we recommend that you don't work on them simultaneously and you should always publish one project before creating the second one.

Target property

Reason for conflict

This conflict occurs when the same property is being modified in two projects using different logic. For example, the extraction rule for the property uses different source columns or formulas.

Best practices

We recommend that you keep the changes from the tenant version and redo the changes in the project because the changes in the tenant version have been validated and released to production.

Business rule order

Reason for conflict

This conflict occurs when changes have been made to the same business rules or multi-subject rules. Rules have either been added, removed, or, reordered in two projects.

Best practices

Because the file is automatically generated, it doesn't matter which change you decide to keep. After you resolve the merge conflict, we recommend that you go back and check that the business rule or multi-subject rules are in the correct order.

Source

Reason for conflict

This conflict occurs when changes have been made to the same source. Changes include:

• Updating the RegexName so that the list of qualifying sources is more/less strict
• New validity range when a file with new columns is loaded
• Source file validation to ensure a column is in the expected type/format, is mandatory/optional, allow/disallow empty

Best practices

We recommend that you keep the changes from the tenant version and redo the changes in the project because the changes in the tenant version have been validated and released to production.