On Mon, Apr 27, 2009 at 9:51 PM, Frederik Ramm <[email protected]> wrote: > (Incidentally - how can a node have only one version and this is > deleted? Would one not have to first create the node, making v1, then > delete it, making v2?)
ah, yes, but previous versions of the API were non-transactional, so (in theory) what happened is that the node was originally uploaded, but failed to enter the history table and existed only in current. it was then deleted, which made an entry in the history table and overwrote the current table. when the 0.6 migration ran it saw only one revision in the history table, so assigned it version 1, since previously nodes only had timestamps, not version numbers. On Tue, Apr 28, 2009 at 10:43 AM, Marko Mäkelä <[email protected]> wrote: > I think that the revision-per-tree approach of Subversion makes much more > sense than the revision-per-file approach of CVS and RCS. The Subversion > model could be impractical for OSM, though. There are so many objects > being edited concurrently, all over the world. While someone is working > on a small local change, the global revision count could easily grow by > hundreds or thousands. there was discussion about having unique (per-upload / other transaction) version numbers global across all element types at the 0.6 hack weekend, but i can't remember why it wasn't popular. > How do distributed revision control systems solve this problem? each element would have a unique version (allocated randomly, or based on user/timestamp/id, etc...) and a set of parent-versions. upon download the client would get all the versions of a particular id which aren't referenced by a parent-version. this doesn't solve conflicts in the same way as DVCS doesn't - it just makes it someone else's problem to do the merge later. (or, in the parlance of DVCS: branches are cheap!) cheers, matt _______________________________________________ josm-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/josm-dev
