[OSM-talk] [OSM-dev] Implementing 'undo' in Potlatch
lists at julius-net.net
Tue Jul 17 15:54:59 BST 2007
Immanuel Scholz <imi at eigenheimstrasse.de> writes:
> Richard Fairhurst schrieb:
>> Easily the most frequently requested Potlatch feature at SOTM was an
>> 'undo' feature.
>> Essentially, because Potlatch is an online editor, I'm going to
>> implement this as a history rollback. In other words, undo will return
>> to the previous version of a way. You can only undo your own work,
>> i.e. you can't roll another person's edits back.
>> So there are two ways to do it:
>> a) Destructive rollback - Delete the most recent version from the
>> database, and set the previous version (and any associated
>> segments/nodes) as current/visible.
>> b) Non-destructive rollback - Set the current version as invisible,
>> then insert the previous version as a new version, thereby maintaining
>> the "undone" version in the history.
>> Given that you'll only be able to undo your own edits, I'm tempted to
>> go for (a). But I would appreciate views from all and sundry,
>> particularly keepers of the flame of database purity such as SteveC
>> and TomH.
> PRETTY PLEASE don't do a). This will much confuse conflict resolving
> algorithms when they accidentally got a snapshot of the state before the
> Just remember that for everything you added, there might be already an
> replication of the data somewhere in JOSM-memory, on hard disk, in
> replication servers, in planet.osms etc... and if you hard-delete your
> data (in the best case) they will just think their state is more recent
> and undo your undo.
I would prefer to have more control over when data is sent to the
server. There already is an upload button to retry failed uploads. I
would like Potlatch not to upload anything when a way is deselected
and only when I hit that button.
Background: Sometimes I temporarily split a way to insert a whole
series of nodes and then merge the way again. Also when creating a
bunch of ways of the same kind I first create the ways then highlight
one, enter the common tags, copy the tags over to the other ways with
Shift-R and then add more tags to individual ways. To sum it up:
Sometimes one creates temporary data or the data gets entered in
several steps and I don't see any value in preserving all that in the
history for all eternity.
Also the longer the time period over which the data is arriving in the
database the higher the chance that someone or some render is
downloading half-finished data.
More information about the talk