Improve change scanner

[tobiasdiez]

If a file is changed externally, JabRef is doing a 3-way merge between the last saved value vs current value in JabRef vs new value in file.
The way this is done is by first comparing the last saved file with the current (changed) file, and then trying to find additional/other changes in the currently open database. This is really complex and I believe there is some subtle bug in the logic leading to #5257.

With this PR, the change scanner is changed to a to simple 2-way merge between the current value in JabRef vs new value in file. This is way simpler and I hope this PR fixes #5257.
In a few edge cases, the 2-way merge has a small disadvantage. For example, consider the following steps:

• User A opens file
• User A changes field Author to User A and adds field Title with value new
• User B opens file
• User B changes field Author to User B
• User B saves file

At this point, User A gets a message that the file changed with the following changes:

• field Author changed from User A to User B
• field Title was removed

The 3-way merge could detect that Title was newly added, and thus could automatically reapply this change. This is no longer possible with the simple 2-way merge.

• Change in CHANGELOG.md described (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for bigger UI changes)
• Checked documentation: Is the information available and up to date? If not: Issue created at https://github.com/JabRef/user-documentation/issues.

[Siedlerchr]

We have to be careful how this works together with a shared database

[tobiasdiez]

The shared databases have their own update/sync mechanism. But I do agree that this should be made consistent at some point.

[koppor]

I am making it consistent in my local dev branch at #5669. That one uses the merge entries dialog as it is the case in the shared database dialog. Does also cover the edge case by @tobiasdiez

[koppor]

Is the reference file updated after the conflicts are reported? (Is it necessary? I would guess: yes, because changes reported should not be reported again - and the reference file is not the bib file on disk)

Is it possible to add some test cases?

[tobiasdiez]

I removed the reference file completely...

[koppor]

Tried it out locally (just local file system, not dropbox), works great.

Just to nitpick comments

[koppor]

How hard is it to embed the merge entries dialog at the yellow place below?

[Siedlerchr]

@koppor The merge entries dialog is already consisting of a BorderPane called MergeEntries which can be embedded easily. See the MergeEntriesDialog

[koppor]

Minor wish: Esc should be enabled for closing the dialog.

(Refs #2949)

[koppor]

@Siedlerchr great! May I ask whether you could do it?

[Siedlerchr]

I if can wait until this evening or afternoon I can try to add it.

[tobiasdiez]

Improved the PR based on the comments. Didn't change anything to the UI as this was not the subject of this PR. So, we are going ahead with this PR and further work on #5669 after the release of 5.0?

[koppor]

This PR has the advantage that it's finished and seems to work 🎉

Maybe we will offer both possibilities:

• transparent merge of changes ([WIP] Fix change on disk detection #5669)
• explicit merge of changes (this PR)

@Siedlerchr Can you do the integration of the merge entries dialog in a separate PR? - This evening is still long and I am really looking forward to it. Meanwhile, I'll work on the other PR.