Operational Notes

When using Next Design and NDGit in a Git development workflow, paying attention to the following points will make operation easier.

Minimize Conflicts

• While NDGit allows for intuitive conflict resolution within Next Design, minimizing unnecessary conflicts will lead to smoother development. Paying attention to the following points will reduce the likelihood of conflicts.

• Dividing model files into smaller parts will reduce the likelihood of conflicts.

• It is especially recommended to separate model files for models that may be developed in parallel.

• Defining the metamodel structure with parallel development in mind will further improve operation.

• For example, one common data definition can be used for reference, allowing for data definition referencing, and then the structure can be divided and designed for each component.

• Furthermore, paying attention to the following will help avoid unnecessary conflicts and improve operation.

• Do not edit the project itself in parallel.

• In particular, do not split, merge, or register references to model files on a branch-by-branch basis.

• Do not edit profiles in parallel.
• Do not edit product line models (especially feature models and configurations) in parallel.

Preventing Model Inconsistencies

In the following cases, the merge result may be an inconsistent model. When merging in the following cases, please check the merged model before use.
If an inconsistent model occurs, please take action according to Warning and handling when loading files or Warnings and Handling Methods When Showing Editors.

1-1. Own split or merged model files, while Other edited the model within those model files.

Conditions for Occurrence

• Own: Performs splitting or merging of model files.

• Other: Edits a model within a model file modified by Own.

Solution

When splitting or merging model files, ensure that no merge occurs.
Example: Other editors pull without committing locally.

1-2. Own moved a model across model files, while Other edited a field of that model.

Conditions for Occurrence

• Own: Performs a model move across model files.

• Other: Edits a model within a model file modified by Own.

Solution

When moving a model across model files, ensure that a merge does not occur.
Example: Other editors pull without committing locally.

1-3. Own changed the model type, while Other edited the model's fields.

Conditions

• Own: Changes the model type.
• Other: Edits the fields of the model that Own changed the type of.

Solution

When changing the model type, ensure that edits to that model are not merged.
Example: Other editors pull without committing locally.

1-4. Own edited the order of child models and referenced models of a model, while Other edited the order of child models and referenced models of the same model.

Conditions for Occurrence

• Own: Edits the order of child models and referenced models of a model.
• Other: Edits the order of child models and referenced models of the same model as Own.

Solution

If a merge occurs after changing the order of models where the order is important, reconfirm that the order is as expected after the merge.

1-5. Own associated a model with a single data point in a field, while Other associated a different model with the same field.

Conditions for Occurrence

• Own: Associating a model with a single data count ("0 or 1" and "1").
• Other: Associating a different model with a model already associated with Own in the same field.

Solution

When a merge occurs after associating a model with a single data count, both Own and Other models are associated, violating the data count constraint.
Check the data count constraint violation using the ribbon [Home] > [Model] > [Check Error].

1-6. Own assigned features to the model, while Other deleted the same model.

Conditions for Occurrence

• Own: Assigning features to the model.
• Other: Deleting the same model as Own.

Solution

When assigning features to a model, ensure that a merge does not occur.
Example: Other editors pull without local commits.

1-7. Own edited the profile, while Other edited the model related to it.

Conditions

• Own: Edits the profile.
• Other: Edits the model that affects Own's profile changes.

Solution

When editing a profile, ensure that a merge does not occur.
Example: Other editors pull without local commits.

1-8. Own added a shape (or connector) to the model, while Other added a shape (or connector) to the same model.

Conditions for Occurrence

• Own: Adds a shape (or connector) to the model.
• Other: Adds a shape (or connector) to the same model as Own.

Solution

• Display the editor and check if the expected shape (or connector) is displayed.
• If the expected shape (or connector) is not displayed, refer to the previous revision and re-edit the shape (or connector).

Note

If multiple shapes (or connectors) exist for the same model, all shapes except the first one found in the editor will be deleted.

In the following case, specifying the left/right direction in a conflict analysis using NDGit may result in an inconsistent model. When performing a conflict analysis, specify left/right to ensure consistency across the project.

2-1. When resolving a conflict between elements with a parent-child relationship, deleting the parent element and adding a child element.

Conditions for Occurrence

• Own: Deleting the model.
• Other: Editing the child model of a model deleted by Own.

In this case, applying the following in the conflict analysis window will result in an inconsistent model:

• Parent model: Applying deletion.
• Child model: Undoing the deletion and applying the changes.

Solution

Apply a consistent direction for parent and child models.
Example: If you delete the parent model, delete the child model as well. Or, if you undo the deletion of the child model, undo the deletion of the parent model as well.

caution

Swaping the edits in Own and Other will result in the same inconsistency.

Making it easier to check text differences

• Since the project is saved in JSON format, you can also check the changes in the model in text. Paying attention to the following points will make it easier to check text differences on Git.

• Including the referenced model path makes the relationship between the source and destination easier to understand.

• Since NDMerge merges on a file-by-file basis, if the model indicated by the referenced path is in a different file, it may not necessarily indicate the correct path.

• In a separate file, the path may change if the name of the referenced model changes or the model is moved.

• You can change the settings and update the reference path to the latest version below.

• You can change the setting under Include referenced model path in Save Options in the Info tab of the ribbon's Backstage.

• You can also update the reference path to the latest version by executing Update Project File under Manage Project Files, also in the Info tab.

• Structuring parent-child elements makes it easier to check additions, deletions, and reorder changes.

• You can change the setting under Save Structured in the Fields item of the Field Inspector.

Preventing Garbled Characters in File Names

When selecting a commit in the repository's commit history, the file names of the changed files displayed may contain Japanese characters, which may result in garbled characters.

info

If garbled characters appear, you can resolve this by setting [core.quotepath] to [false] as follows.

git config --global core.quotepath false

Do not perform file operations during Git operations

• Performing file operations while a Git operation that takes time to complete is running may cause inconsistencies.
• File operations include changing the hierarchy or renaming model files in the Project Navigator.

Related Topics

• Overview of Team Development with Git