On Fri, May 16, 2008 at 9:18 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > Hi, > >> > Use your imagination then. If the user requests, say, a graphical >> > representation of the changes effected by change set X, you will not >> > want to show the intermediate steps. So you would have to collapse the >> > change set - something changed first and deleted later, show it only as >> > deleted; something created at position A and moved to position B, show >> > it as created at position B; something moved from X to Y and then from Y >> > to Z, show it as moved from X to Z. >> >> It is trivial to do that kind of stuff on the clientside. > > Not trivial, and a benefit for all if implemented server-side.
Umm.. maybe I missed something but surely this is trivial? For any OSM object where we have N states: o1, o2, o3 ... oN we can easily collapse the change to o1, oN osm objects are atomic is this respect. > >> First of you might want to do rollback from Z to Y only because >> you want to keep Y to X. > > Changesets are a grouping of edits that make things easier because one > only has to work with the groups - e.g. not show all individual edits, > but show the group as a whole, etc. > > A changeset can only be rolled back as a whole. The rollback of a > changeset leads to a new, "inverted" changeset that should be tagged > in a way to express the fact that it is a rollback of changeset X. > > If you want to do partial rollbacks, then you don't need changesets at > all - you might as well go with the already implemented "restore > historic version" function in Potlatch. > > In that case you lose the changeset being rolled back - you do "some > changes" but you don't do a "rollback of a changeset". > > It is fully ok for clients to use the history of individual objects to > return them to any state they were in at some time before, like > Potlatch does, but this has nothing to do with rolling back > changesets. > > I'm a bit tired of this. I understand that you're unhappy about not > having been at the hack-a-thon but can we perhaps now proceed with the > work at hand instead of making an endlessley protracted discussion > about every single aspect of the new API. (The longer this goes on, > the more reason there is for those that will one day do 0.7 to *not* > discuss things on the lists, citing this discussion as an example that > nothing good comes of it.) Rollback and the retrieval of changeset > data aren't even on the critical path, they can be implemented at > *any* *later* *time* without changing the API. We don't have to find a > solution today. > > You want changesets as some universal access and documentation method > for the history of everything, and I want them as closed, near-atomic > changes. I'd say the person who codes it gets to decide, but as I > said, it doesn't even have to be decided now. > > Bye > Frederik > > -- > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
