Modify

Opened 11 years ago

Last modified 2 years ago

#8660 reopened defect

[Patch] False positive conflict detection with reverter plugin

Reported by: skyper Owned by: Upliner
Priority: normal Milestone:
Component: Plugin reverter Version:
Keywords: conflict node Cc:

Description

Thought there was already a ticket about it, but I did not find it.

I get these false positives when reverting but I am not sure if it does happen with other merges,too.
The problem appears with younger nodes than the reverted changeset.

  1. revert changeset 14914753.
  2. got 64 conflicts
  3. look at conflict of node id:980535480
  4. there is no conflict and you do not have any option to change anything.

The reported conflict is useless.

I am not sure weather these are conflicts and you need some options in the conflict manager or not and the whole conflict should be dropped.

Attachments (3)

test.osm.bz2 (610.8 KB ) - added by GerdP 5 years ago.
conflict.PNG (30.5 KB ) - added by GerdP 5 years ago.
8660.patch (2.1 KB ) - added by GerdP 5 years ago.
Please review: This patch suppresses useless conflicts which are typical when you revert a changeset that was already reverted by a more recent cs

Download all attachments as: .zip

Change History (16)

comment:1 by Don-vip, 11 years ago

It also produces an exception if we click on the left button of the tags tab:

Identification: JOSM/1.5 (5929 SVN en_GB) Windows 8 64-Bit
Memory Usage: 194 MB / 1813 MB (64 MB allocated, but free)
Java version: 1.6.0_45, Sun Microsystems Inc., Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Dfile.encoding=UTF-8]
Dataset consistency test: No problems found

Plugin: reverter (29559)

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
	at java.util.ArrayList.RangeCheck(ArrayList.java:547)
	at java.util.ArrayList.get(ArrayList.java:322)
	at org.openstreetmap.josm.gui.conflict.pair.tags.TagMergeModel.rememberDecision(TagMergeModel.java:136)
	at org.openstreetmap.josm.gui.conflict.pair.tags.TagMergeModel.decide(TagMergeModel.java:164)
	at org.openstreetmap.josm.gui.conflict.pair.tags.TagMerger$KeepMineAction.actionPerformed(TagMerger.java:283)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
        ...
Last edited 11 years ago by Don-vip (previous) (diff)

comment:2 by Don-vip, 11 years ago

Ah, the exception is a dupe of #5680.

comment:3 by Don-vip, 11 years ago

Component: CorePlugin reverter
Owner: changed from team to Upliner

comment:4 by Don-vip, 11 years ago

Resolution: fixed
Status: newclosed

Fixed in [o29561].

comment:5 by Don-vip, 11 years ago

Resolution: fixed
Status: closedreopened

Looks like it is not yet fully fixed as I found several useless conflicts while reverting changeset 15875597.

comment:6 by Don-vip, 11 years ago

Summary: False positive conflict detection with nodes (reverter)False positive conflict detection with reverter plugin

(with ways, I think I have fixed the problem only for nodes in fact)

by GerdP, 5 years ago

Attachment: test.osm.bz2 added

comment:7 by GerdP, 5 years ago

I can still reproduce useless conflicts when loading the attached file and reverting 15875597 with current binaries,
e.g. way 75022047 is not modified but I see a conflict. I'll have a closer look again.

by GerdP, 5 years ago

Attachment: conflict.PNG added

comment:8 by GerdP, 5 years ago

I fear I don't fully understand the concept of the conflicts produced by reverter.
Example:
I download a small area around node 5145791503 which - as of now - has a history of 3 versions. The data
also contains the way 529734514.
Let's assume I like the version 1 better, so I revert the cs 52802997 which changed it to v2.
I revert with "revert selection only" and I get a conflict (unexpected).
The code in the plugin detects a conflict because it compares v2 with the version in my data (v3)
and finds that the coordinates are different. This is the reason that the conflict that is created.
The conflict displayed in the dialog also claims that version 3 of the node is not member of way 529734514,
which is simply wrong as the node is still a member of the way (on the server and also in my data).
Am I right that my revert should not produce a conflict?

Last edited 5 years ago by GerdP (previous) (diff)

by GerdP, 5 years ago

Attachment: 8660.patch added

Please review: This patch suppresses useless conflicts which are typical when you revert a changeset that was already reverted by a more recent cs

comment:9 by skyper, 2 years ago

Summary: False positive conflict detection with reverter plugin[Patch] False positive conflict detection with reverter plugin

ping

comment:10 by skyper, 2 years ago

I just got completely useless conflicts without the use of reverter plugin. The problem is that the objects were deleted while I was editing. Upload worked as I had not modified the objects but an update data produced conflicts. My CS is changeset/114720352 and changeset/114716346 is the CS deleting the objects. The following objects produced useless conflicts with both object versions being identical and latest.

comment:11 by GerdP, 2 years ago

No idea how to reproduce. Maybe you changed the relation 12600575?
Why do you add this comment to a ticket that is about reverter?

Last edited 2 years ago by GerdP (previous) (diff)

in reply to:  11 comment:12 by skyper, 2 years ago

Replying to GerdP:

No idea how to reproduce. Maybe you changed the relation 12600575?

Yes, I had modified it, but got no conflict on upload. The relation was still present. Only after update data, the relation was invisible (deleted).

Why do you add this comment to a ticket that is about reverter?

I am not sure if the useless conflicts are a problem of reverter plugin or DataMerger. Next time I will open a new ticket and leave the decision for someone else if it is a duplicate or an own problem, sorry.

in reply to:  11 comment:13 by skyper, 2 years ago

Replying to GerdP:

No idea how to reproduce.

That was another reason for not opening a new ticket. I had this conflicts which I could not save and was kicking my ass that I did not clone the original layer prior of updating the data.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as reopened The owner will remain Upliner.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from Upliner to the specified user. Next status will be 'new'.
Next status will be 'needinfo'. The owner will be changed from Upliner to skyper.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.