On Thu, May 15, 2008 at 11:31:13AM +0200, Frederik Ramm wrote: > >> Under the current plan, yes. We didn't think it was reasonable to > >> push that assumption down to the clients thought. > > Why would that be unreasonable? In what (futuristic) scenario would > > version numbers not increment monotonically one by one? > In the current scenario, you are basically not allowed to upload a new > version of an object if you haven't got the previous version. > > This is unnecessarily strict. > > For example, two people could download version 1 of a node; one adds the > foo tag, another adds the bar tag, both upload. With the plans for API > 0.6, one of the uploads will simply fail. > > In theory, both uploads could be accepted without conflict, and we would > then have one change that goes from v1 to v2, and one change that goes > from v1 to v3.
But one of them will be accepted first and the other will later be judged as sufficiently different, right? So the actually history in the database will have two transitions, one from v1 to v2 and the other from v2 to v3. > It is also possible to change the same object multiple times within the > same changeset, so one single changeset might catapult the object > version from 1 to 15. Wouldn't it be better then to just throw away consecutive changes to the same object and only keep the last one within each diff? cu bart _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
