On 3 Sep 2009, at 10:05, Pieren wrote: > On Thu, Sep 3, 2009 at 10:29 AM, Dave > Stubbs<osm.l...@randomjunk.co.uk> wrote: >> As far as I know most of the tools used for reverting currently are >> also public -- the problem being, they're dangerous to use if you >> don't know what you're doing, not at all user friendly, deliberately >> hard to use to make sure you do know what you're doing, and not >> remotely capable of dealing with conflicts. >> >> Dave > > That's where I disagree. We should stop considering 'revert' as > 'dangerous to use if you don't know what you're doing'. It is not more > dangerous as any other edits, it's just a different way to select > elements and modify them. The only difference is that you refere to a > particular state of the dataset (changeset) which might be obsolete > (in which case the 'easy revert' should be aborted) in the same way as > when two contributors work in parallel in the same area. > We cannot say in one side "let the crowd create, modify or delete > elements as easy as possible" and in the other side "make revert hard > to use". > I'm still in favour of having an "easy revert" as a first attempt on > the main site and only provide more complexe tools into editors in > case of conflicts.
I agree that there should be a 'easy revert' for a single changeset. This might result in a 'clean' revert (where none of the features have been touched since), a partial success with a conflict report (where only some features could e reverted because they have already been deleted or whatever), or a total failure (possibly where the changeset has already been reverted). This is not of course a 'revert' in that the original changeset will still be in the history, its just that the data will be back to the original state. > But you will have to explaine how you deal with the > 145 changesets of RR8 if you have to enter manually each number in > your editor. When it comes to reverting multiple changesets there will be a benefit to doing them all together possibly, or strictly in reverse order. Possibly this might need a different approach. If we can do it easily then great (one would normally select a single user and a date range to catch the relevant changesets). An absolute essential is that a revert shows up as a changeset with a description that includes the fact that it was a revert and what it was reverting and can itself be reverted. At some point we might need a speed tile redraw to get embarrassing stuff out of the tile stack quickly. Regards, Peter > Pieren > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
