[OSM-dev] [OSM-talk] Trouble in Rangoon

Frederik Ramm frederik at remote.org
Thu Feb 28 15:10:27 GMT 2008


> node a is initially at state a0
> - user X create_changeset 1
> - user X change node a to state a1

> - user Y create_changeset 2
> - user Y change node a to state a2
> - user Y close_changeset 2

> - user X change node a to state a3
> - user X close_changeset 1
> Now revert changeset 2.

Changeset 2 cannot be reverted cleanly because the node is in state  
a3 but would have to be in state a2 in order for changeset 2 to be  
reverted cleanly. The user would possibly get a message informing him  
of the fact, and either asking him to somehow get the node into state  
a2 OR make a dirty revert.

This is completely independent of whether or not the later change a2- 
 >a3 happens in a changeset that was begun earlier than Y's.

If changeset 2 were to be reverted dirty, the node would of course  
revert to a1 since that was the state the node was in before the  

Changesets only group changes, they do *not* replace the existing  
version numbering of objects! If you think about how we handle things  
now: We have a timestamp on every object, but the "current" object is  
always the one with the highest sequence number, not the one with the  
most recent timestamp. I am suggesting to move the timestamp into the  
change group - as it is only informational anyway - but the sequence  
number remains the decisive element in determin which version of a  
node is current.

The only thing slightly quirky about your example is that a node is  
changed twice as part of the same changeset. That doesn't make sense  
to me but maybe I'm too JOSM-minded; in a live editing scenario with  
Potlatch this might well happen.

> To what state should node a revert? a0, a1, or a3?
> And this is even a 'simple' case. But imagine much more complex  
> scenarios
> where user Y is actually changing a turn restriction while user
> X is changing the direction of one of the ways that is part of said
> turn restriction.

Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'

More information about the dev mailing list