Skip to content

Handling of Modified Dates

Almost all types of elements/diagrams in an Enterprise Architect have some kind of "modified date", which reflects the last time this element or a part of it has been changed by the modeller.
When merging models, LemonTree ignores the modification date of elements/diagrams completely.

The reasoning for this decision is explained below.

Impact of Modification Dates on Three-Way Merges

To understand why LemonTree ignores modification dates, it is crucial to understand the possible impact of modification dates on a three-way merge. 

During a three-way-merge, any parallel modification of the same elements/diagrams leads to a guaranteed conflict in the modified date.

This leads to a significant number of conflicts to process and display, which usually do not have any significance for the user on their own.

Benefits of Ignoring Modified Dates

Cutting down the number of conflicts detected during a three-way merge by ignoring the modified dates has clear advantages:

  • The list of conflicts is significantly less cluttered
  • Three-way merges containing only conflicts in the modified dates can be performed automatically

The second point in particular is the reason LemonTree works the way it does. In automatic merge scenarios, LemonTree aims to minimize required user interaction wherever possible.

Drawbacks of Ignoring Modified Dates

Of course, the decision to ignore the modification dates completely has its negative impacts:

  • the LemonTree UI does not show when modified elements/diagrams have been changed
  • The modified date of elements/diagrams is left unchanged during a merge.
    This negatively impacts two-way merges in particular, as these merges do not gain any benefit from ignoring the modification dates.