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

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


Hi,

> 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  
operation.

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