Reproducible bug in "review changes"

[wilthan]

JabRef version 3.3 and also in
JabRef 3.4dev--snapshot--2016-05-19--master--ed638e2
windows 7 6.1 amd64
Java 1.8.0_66

When multiple users (in the test case: 2) work on the same file which is located on a network drive.

Steps to reproduce:
1 (Pc1) open database (Pc2) open database
2 (Pc1) create test
3 (Pc1) save
4 (Pc2) review changes
5 (Pc2) add entry-accept
6 (Pc1) save
7 (Pc2) review changes
8 (Pc2) delete entry accept
9 (Pc2) save
10 (Pc1) review changes
11 (Pc1) delete entry-not accept
12 (Pc1) save
13 (Pc2) review changes
14 (Pc2) add entry-accept
15 (Pc1) save
16 (Pc2) review changes
17 (Pc2) delete entry -not accept

After step 5 both local copies should be identical with the file content. Regardless, after saving again another change shows up and now wants to delete the previously added file.

On a large scale you add up with multiple copies of the same reference and/or a deleted reference, dependent on what changes each user accepts. We had to go back to 3.2, it also shows glitches with multiple users on one file but less often and so far, not reproducible.

[stefan-kolb]

Thanks for your report 👍
We are working on improving multi-user support. Stay tuned.

[koppor]

Refs #970.

[SimSonic]

From time to time we have 3-4 users working on the same db.bib file (about 6500 referencies in it). File is located on network drive. Sometimes someone loses their changes. Not all users are so advanced to see Review changes block in the sidebar.

As I see the workflow: Two users open db.bib file and edit some entries (add/fix/remove) for a long time. Each JabRef instance remembers what entries are modified by local user. Regulary (after autosave timeout) local file with changes is saved. When second instance finds that remote file is changed it should merge changes from local memory and remote file that are not intersecting (and maybe run autosave again in the background).

For intersecting changes show Review changes and highlight (blink?) it somehow on sidebar.

Thanks.

[wilthan]

The bigger problem for us is not that Review changes is not visible enough, it just has a bug.
We did some more testing and can even reproduce it on one PC with two instances of JabRef opened.
The easiest test is:

• open the same file in two different JabRef instances (1 and 2)
• in 1: add new BibTex entry (article)
• in 1: save file
• in 2: Review changes shows up -> click it and accept changes (do not save the file)
• in 1: don't change anything and save file again
• in 2: Review changes shows up -> now it wants to delete the added article while nothing has changed!

Version 3.2 does not have this issue but 3.3 and 3.4 do.

I know you work hard on the data base connection feature but maybe there is a fast fix for this in the meantime...

[stefan-kolb]

@JabRef/developers WDYT?

[koppor]

I would try to create a test case checking for this behavior. Then run git bisect to find out which commit smashes the behavior. My guess is that #1126 could have something to with it, but I'm not sure at all.

[simonharrer]

#1126 is not related as it was released only in 3.4, but not in 3.3. Hence, the issue is caused by something else.

[simonharrer]

Error somehwere in between these 80 commits a71c2b0...fc7e175

Will try to refine it further.

[simonharrer]

Quite complicated. It is probably related to the IDs of BibEntries. Here my git bisect log

# bad: [fc7e175b3e79c268d6210a83ad307e7e1710f28f] Removed method placeDialog
# good: [a71c2b0de5568f11aa73a1dbafc8b82e5da8b91a] Merge pull request #981 from oscargus/nomoreprintstacktrace
git bisect start 'fc7e175b3e79c268d6210a83ad307e7e1710f28f' 'a71c2b0de5568f11aa73a1dbafc8b82e5da8b91a'
# skip: [59e38da438d097a7701225789279a5e52c2fbf47] Merge pull request #1020 from oscargus/filefieldtranslations
git bisect skip 59e38da438d097a7701225789279a5e52c2fbf47
# skip: [31125c16070c351cb12299cffdd8dca3724a911c] French localization: translation of empty strings
git bisect skip 31125c16070c351cb12299cffdd8dca3724a911c
# skip: [e6357375e4799c8aaae278856e817784f08346a9] Disabled NPE test
git bisect skip e6357375e4799c8aaae278856e817784f08346a9
# skip: [01772dc5082523ddc22558846f09153edd85bd78] Merge pull request #1016 from oscargus/showzoomlevel
git bisect skip 01772dc5082523ddc22558846f09153edd85bd78
# skip: [5affc1b26aa9d2bf3ee3365ae78007bd8f1cdeb5] Removed unused support for creating a new entry by dragging a file and dragging multiple files
git bisect skip 5affc1b26aa9d2bf3ee3365ae78007bd8f1cdeb5
# skip: [8fd97f5363584a00b3c2b14cb813f4d09cb66de5] Simplified translations in SynchronizeFileField
git bisect skip 8fd97f5363584a00b3c2b14cb813f4d09cb66de5
# skip: [1ffcedf9847d3cdc5ae1afe561b85b773dc07848] Remove Optional for String value and enforce empty String
git bisect skip 1ffcedf9847d3cdc5ae1afe561b85b773dc07848
# skip: [8c208a0380ecf96f14272f71326a65c7299656f4] Use static method inside tests
git bisect skip 8c208a0380ecf96f14272f71326a65c7299656f4
# skip: [be288d086ceb3b24f45d6bde37f71fbdd96a7840] Fixed problem with Filepath Paths.get(url.toUri()).toFile() is now the correct way to handle Files from URLs. See http://stackoverflow.com/questions/6164448/convert-url-to-normal-windows-filename-java
git bisect skip be288d086ceb3b24f45d6bde37f71fbdd96a7840
# skip: [57963f792beab60a4d43cd95056c34e997d58207] Merge pull request #982 from tobiasdiez/importOrder
git bisect skip 57963f792beab60a4d43cd95056c34e997d58207
# good: [792995792a0c75580713b687307f64145490a9d1] Fix compilation error
git bisect good 792995792a0c75580713b687307f64145490a9d1
# skip: [e477631e657359fba6e7dc3af758b18be93fc7ac] Merge pull request #1010 from oscargus/exportformattest
git bisect skip e477631e657359fba6e7dc3af758b18be93fc7ac
# good: [7965ce6496e5340642294dcc6d8c73023fc32165] Merge pull request #974 from tobiasdiez/alwaystrim
git bisect good 7965ce6496e5340642294dcc6d8c73023fc32165

[simonharrer]

Okay, I have wrote a fix, but I am not completely sure whether this really solves the problem. Maybe you could also help to test this. In a few minutes, a new release in the fix-1430 folder will be available at http://builds.jabref.org/fix-1430/ - could you confirm that this fixes your issue?

[wilthan]

WOHOOO - it works!
I first tested the wrong fix (fix-1476) ...
fix 1430 does resolve the short test case I submitted yesterday.
We'll test it some more during the day and I'll keep you updated.
thx a lot!

[simonharrer]

Excellent. Sadly, there are no automated tests for the collaboration feature - hence we currently rely on user feedback. But we are open for contributions in that area, if someone wants to put this under test.

[simonharrer]

@wilthan any news regarding further testing?

[wilthan]

@simonharrer: we did not see any more issues during our regular work. Typically we have 3-5 people working with one network file for about 8h a day.
-> the fix 1430 seems to have resolved the issue
thx again!

[simonharrer]

Ok, will merge it in. Thanks for the feedback! :)