Empty merger conflicts - better reporting?

[Jeff Heath]

It seems to me that in most cases when I do a FieldWorks Send/Receive and there are merger "conflicts", that the conflicts are basically empty.

For example, I just did a S/R on a project and there are numerous "merger" conflicts in the Conflict Report that popped up at the end. If I open the Conflict Details, the only differences are:

Jack 2022 12's changes: <DictionaryConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Root-based (complex forms as subentries)" version="25" lastModified="2026-01-26lastModified="2026-02-02" allPublications="false" isRootBased="true">

jeff_'s changes: <DictionaryConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Root-based (complex forms as subentries)" version="25version="26" lastModified="2026-01-26lastModified="2026-01-30" allPublications="false" isRootBased="true">

(If that doesn't come through in the post, it just shows that the attributes version and lastModified changed.)

I'm wondering if this is actually a data model change, and the problem would be resolved if the team members moved to the same version of FieldWorks.

But I'm also wondering if there could be a better way to report this error. As it is, I assume that the diligent user would have to page through those hundreds of screen fulls of differences to see if there are any other little details that changed (and not just those headers), as shown by text marked in red and yellow. If FieldWorks does a diff on the two versions of the record and finds that the ONLY change is in the version number (and the lastModified field), couldn't it just give a message: "Warning: Users of this project (Jack and jeff_) are using versions of FieldWorks with different data model numbers. It is recommended to update the entire team to the same version of FieldWorks." The entries are otherwise identical, so IMHO there is actually no need to insert a conflict in the Project Notes. What do you think?

Thanks,

Jeff

[Ken Zook]

Jeff,

 

I think you have users on FW9.3.5 and others on older versions. This is causing a problem when FW9.3.5 and older versions sync because 9.3.5 incremented the version number to 26, but when an older version syncs, it ends up putting it back to 25, and the battle continues until all colleagues upgrade to FW9.3.5. We weren’t aware that this would happen when that change was made. Sorry.

 

Ken

--
"FLEx list" messages are public. Only members can post.
flex_d...@sil.org
http://groups.google.com/group/flex-list.
---
You received this message because you are subscribed to the Google Groups "FLEx list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flex-list+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/flex-list/b0c575b7-929c-4197-8f7b-e1dd92523b27n%40googlegroups.com.

[Ken Zook]

P.S. This is not a data model change, but just a configuration model change. If FLEx actually upgrades to a new data model, users will not be able to sync with users at a different model level. Special warnings are given in this case to try to help users understand the problem. The last data model change was made in 2018 and we’ve tried to avoid upgrading that because it is a major change for S/R.

 

Ken