[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