JOSM doesn't allow me to deal with conflicts when local version is higher than server version

[per4ik35@…]

Trying to upload changeset. If there some warnings I deal with them and then upload. When changeset has points to modify it tells me that there are conflicts to handle. Clicking on synchronize all and nothing display. It happens every time and I can't upload anything

[GerdP]

Ticket #18981 has been marked as a duplicate of this ticket.

[GerdP]

Thanks for your report, however your ticket is incomplete and therefore not helpful in its current form.

Please add all needed information according to this list:

• The required parts of the Status Report from your JOSM.
  • Please, use Report Bug from Help menu and copy & paste.
• Describe what behaviour you expected.
• Describe what did happen instead.
• Describe if and how the issue is reproducible.
• Add any relevant information like error messages or screenshots.

To ensure that all technical relevant information is contained, create new tickets by clicking in JOSMs Main Menu on Help → Report Bug.

Remember: This is a generic notice so we don't need to write the same stuff again and again. It may only apply in parts to the specific case!

[per4ik35@…]

What steps will reproduce the problem?

1. Open the changeset with points which "action"="modify"
2. Resolve warnings if they exist
3. Press button upload
4. Add comments and press button send to server
5. On appeared window with conflicts select synchronize

What is the expected result?

To see what conflicts have to be resolved

What happens instead?

Nothing appears

Please provide any additional information below. Attach a screenshot if possible.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-02-26 10:50:27 +0100 (Wed, 26 Feb 2020)
Build-Date:2020-02-26 09:52:41
Revision:15937
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15937 ru) Mac OS X 10.14.6
OS Build number: Mac OS X 10.14.6 (18G95)
Memory Usage: 920 MB / 1820 MB (411 MB allocated, but free)
Java version: 1.8.0_241-b07, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: Display 2077749241 1680x1050
Maximum Screen Size: 1680x1050
VM arguments: [-Djava.library.path=/Applications/JOSM.app/Contents/MacOS, -DLibraryDirectory=${HOME}/Library, -DDocumentsDirectory=${HOME}/Documents, -DApplicationSupportDirectory=${HOME}/Library/Application Support, -DCachesDirectory=${HOME}/Library/Caches, -DApplicationDirectory=${HOME}/Applications, -DAutosavedInformationDirectory=${HOME}/Library/Autosave Information, -DDesktopDirectory=${HOME}/Desktop, -DDownloadsDirectory=${HOME}/Downloads, -DMoviesDirectory=${HOME}/Movies, -DMusicDirectory=${HOME}/Music, -DPicturesDirectory=${HOME}/Pictures, -DSharedPublicDirectory=${HOME}/Public, -DSystemLibraryDirectory=/Library, -DSystemApplicationSupportDirectory=/Library/Application Support, -DSystemCachesDirectory=/Library/Caches, -DSystemApplicationDirectory=/Applications, -DSystemUserDirectory=/Users, -DUserHome=${HOME}, -DSandboxEnabled=true, -DLaunchModifierFlags=0, -DLaunchModifierFlagCapsLock=false, -DLaunchModifierFlagShift=false, -DLaunchModifierFlagControl=false, -DLaunchModifierFlagOption=false, -DLaunchModifierFlagCommand=false, -DLaunchModifierFlagNumericPad=false, -DLaunchModifierFlagHelp=false, -DLaunchModifierFlagFunction=false, -Dapple.laf.useScreenMenuBar=true, -Dcom.apple.macos.use-file-dialog-packages=true, -Dcom.apple.macos.useScreenMenuBar=true, -Dcom.apple.mrj.application.apple.menu.about.name=JOSM, -Dcom.apple.smallTabs=true]
Dataset consistency test: No problems found

Plugins:
+ reverter (35313)

[GerdP]

I cannot reproduce the result without knowing the exact object that caused the conflict. I tried with a node where the server had a newer version and got the conflict dialog. If I got that right it might be possible that the conflict was resolved by clicking on the Synchronize button.
Please check if the changeset was closed. Please let us know the changeset id or the object.
If you still have the file with the change please attach it.

[per4ik35@…]

Example of file

[GerdP]

OK, your file says the node is version 10 but the latest server version is 9.
When I download the node from the server and modify its position JOSM doesn't change the version to 10. How did you create this file?

[per4ik35@…]

It wasn't created by but by some script at my work. It is taking info about points from database and recently imported. By comparing them it is creating files for JOSM. You said about version, my file doesn't have the right one or it is have to be +1 when we are creating changeset with points to modify

[anonymous]

Replying to per4ik35@…:

It wasn't created by but by some script at my work. It is taking info about points from database and recently imported. By comparing them it is creating files for JOSM. You said about version, my file doesn't have the right one or it is have to be +1 when we are creating changeset with points to modify

*wasn't created by me

[GerdP]

I can only say that JOSM doesn't expect to find a version which is higher than the one on the server.
The idea of conflict management is that you download a specific version of the object, modify it and try to upload. If the object was changed in another changeset the version on the server will not match yours and the server replies that there is a conflict. So, you should never change the version on your side, the server answers with the new version if the upload was successfull.

[GerdP]

If my understanding is correct JOSM should show a warning that the local version is higher than the server version.

[per4ik35@…]

Hm, I didn't have such warning

[per4ik35@…]

Right now I tried to upload same file with version 9 and it worked! Looks like it was a problem

[GerdP]

Replying to per4ik35@…:

Hm, I didn't have such warning

I suggested this message as an improvement.

[anonymous]

Can this feature be seen in last stable version?

[GerdP]

Only when someone implements it. The current code explicitely ignores the case that the local version is higher than the server version. I don't know why, the code works like that since more than 10 years.

[GerdP]

@team: The problematic code is in DatasetMerger.mergeById():

        if (target.getVersion() > source.getVersion())
            // target.version > source.version => keep target version
            return true;

Do we have this code to handle the case that a server version was redacted? If yes, shouldn't this produce some kind of notification or a dialog? I see two possible scenarios:
1) User downloads data with version x and modifies it -> server version x is redacted - > user tries to upload and gets a conflict.
2) User edits the object and increases the version outside of JOSM (this is what happened here).

What should JOSM do? Is there a way to distinguish these two cases? My suggestion would be:
For 1) Replace the modified object with the server version so that the user doesn't work with redacted data and maybe show a popup/notification
For 2) Show notification that the server version is lower than that of the local object. Offer to reduce it or do this automatically?

[GerdP]

Any suggestions?