On Mon, Aug 23, 2010 at 10:29 AM, Scott Crosby <[email protected]> wrote: > Pretending changsets are atomic lets me > define/construct one such ordering, using changeset numbers or ending > timestamps.
Just so you're aware, the closing time for changesets does change, though it usually does so within a short period of time. If you look at the historical changeset dumps, you'll notice this. On Mon, Aug 23, 2010 at 11:40 AM, Scott Crosby <[email protected]> wrote: > An upload by 'POST /api/0.6/changeset/#id/upload' is guaranteed to be atomic. You can make more than one upload for a single changeset, though. > If the history is to obey the atomicity constraints and be immutable, > the only feasible way for timestamps to be used for ordering, is if > they are set by the server, upon upload of the OsmChange, and the same > for each element. They must be set by the server because only the > server can create timestamps that are guaranteed to never be in the > past. They're not the same for each element. But why do they need to be? As long as a way does not refer to a node with a later timestamp, this should be fine, right? Yes, it would be nice if changesets were truly atomic. But they just aren't. Changesets aren't really useful for anything other than assigning tags (like "comment" and "created_by") to multiple element updates. The fact that they're called "changesets" is basically a misnomer. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
