On Thu, May 15, 2008 at 5:13 PM, Dirk-Lüder Kreie <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dave Stubbs schrieb: > >> It's also possible for another changeset to edit the object in between >> as well, so this probably shouldn't be as transparent as "catapult" >> might suggest. The changeset data download will have to take this into >> account. > > How do you handle rollback in such a case? >
You either: - ignore it (the changeset is atomic per object approach), or - you treat it like a conflict and only roll back as far as the other changeset's change. The user then gets to resolve the remaining changes by whatever conflict resolution the editor provides (the same as they're going to have to for edits that effect the object since the changeset closed) The changeset data download can make one approach easier than the other, but as each object still has it's own queryable history, you can continue to do either. The basic types of changeset query I can think of are: - atomic objects: you get before, and you get after for each changed object - grouped objects: each consecutive change made by this changeset is grouped together with only before and after for each group. So each time another changeset gets involved we get a new before/after set. - raw edits: every single edit is returned Some are going to be easier to implement than others. Dave _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
