revert plugin: cannot revert change set if objects not already in data set

[bastiK]

Reverting a change set fails. I started with a blank layer.

GET http://api06.dev.openstreetmap.org/api/0.6/changeset/3859
GET http://api06.dev.openstreetmap.org/api/0.6/changeset/3859/download
GET http://api06.dev.openstreetmap.org/api/0.6/way/85190/2
GET http://api06.dev.openstreetmap.org/api/0.6/node/3553144/1
GET http://api06.dev.openstreetmap.org/api/0.6/node/3553143/1
GET http://api06.dev.openstreetmap.org/api/0.6/node/3193882/2
java.lang.IllegalStateException: Missing merge target for node with id 3,195,563
	at reverter.DataSetToCmd.mergeNodeList(DataSetToCmd.java:115)
	at reverter.DataSetToCmd.fixReferences(DataSetToCmd.java:89)
	at reverter.DataSetToCmd.merge(DataSetToCmd.java:157)
	at reverter.DataSetToCmd.<init>(DataSetToCmd.java:37)
	at reverter.ChangesetReverter.RevertChangeset(ChangesetReverter.java:109)
	at reverter.RevertChangesetAction$1.realRun(RevertChangesetAction.java:44)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:83)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:129)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

[bastiK]

Hi Upliner,

are you still working on it?

[Upliner]

I forgot about it. Thanks for the reminder, bug will be fixed soon.
In fact I consider that reversion of changesets is quite rare operation to bother about it too much.
Probably I'll develop it more actively when there is more evidence of vandalism Russia...

[bastiK]

On the contrary, a user friendly revert tool is really needed!

When it works reliably, we can promote it more.

I like the way you could use the existing conflict resolution framework to solve an inherently complicated problem (reverting a botched changeset). Very elegant. :)

[Upliner]

Quite frankly, I dislike the JOSM conflict system.

First, it's not really user friendly, it's not possible to clearly see "my" and "their" versions. At this time it's not possible to force "my" or "their" version for all objects which would be useful for "dirty" reverts.

Second, it's two-way instead of three-way. In case of reverter I have three versions of object: current version, changeset version and version before changeset(changeset-1). In case of clean revert changeset and current versions are same. Which version should I mark as "their"? Current version or changeset version?

In the long run I plan to create my own diff-view and conflict resolution system.

[stoecker]

Rather than developing your own version it would be much better to improve the one in core.

[Upliner]

I decided to use current version as "their" because it is explained as "server dataset".

Try out the new version of plugin(21625), the bug should be fixed.

[bastiK]

Replying to Upliner:

Quite frankly, I dislike the JOSM conflict system.

Sure there is room for improvement. But it should be possible to gradually improve it, so it becomes intuitive and easy to use some day.

First, it's not really user friendly, it's not possible to clearly see "my" and "their" versions. At this time it's not possible to force "my" or "their" version for all objects which would be useful for "dirty" reverts.

The last suggestion is a relatively easy change, don't you think?

Second, it's two-way instead of three-way. In case of reverter I have three versions of object: current version, changeset version and version before changeset(changeset-1). In case of clean revert changeset and current versions are same. Which version should I mark as "their"? Current version or changeset version?

It is a similar situation with normal conflicts, you have 3 versions:

(A) the one your changes are based on

(A*) the changed state of these objects

(A+i) the version on server

However both parties agree, that (A) is outdated and need not be considered. So you end up with conflict between A* (my) and A+i (their).

With revert of changeset I would think of it like this: A is the cs version, A* is the version before cs and A+i the current version. (For clean revert i=0, so A=A+i.) Both parties agree, that A is no longer relevant, so you have only conflict between A* and A+i.

(On the other hand, both are somehow a modification of A, so it might improve usability to not only show A* and A+i but somehow visualize A->A* vs. A->A+i.)