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. > 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
