When merging, the conflict resolution between matching entries (using the UUIDs) is done by replacing the entry with the oldest modification date with the entry with the most recent modification date. This is ok in most cases, but can cause data loss if an entry is modified from 2 different places within a single merge cycle.

Expected Behavior

Merging 2 entries should be fine-grained and resolve the conflicts on a field level to avoid data loss.

Current Behavior

Merging 2 entries might result in data loss if the entry was modified from 2 different places.

Possible Solutions

1- We could at least store the entry that "lost" the conflict resolution in the history, if it's not already there. This is not ideal, as the user might not even be aware that a conflict resolution took place.

2- We could add modification dates for all the fields of an entry. This way we could resolve conflicts on a per-field basis. I'm not sure if this would be compatible with the KeePass format though.

3- We could compute the modification dates for the different fields by rewinding through the history. This would not require adding new fields to the database file. The drawback is that currently the history and history size are configurable, so if the history is not enabled, we have to fallback to the current merging behavior.

Steps to Reproduce (for bugs)

1- username modified in first database
2- password modified in second database
3- both databases are synchronized using the merge functionality.
4- the username modification from the first database is lost.

Context

There has been a lot of requests for automatic synchronization lately, and I think if we are to support such a feature, we should definitely make sure the merge/sync function reduces as much as possible data-loss.