[josm-dev] Deletion conflicts

[Matt Amos]

On Mon, Apr 27, 2009 at 9:51 PM, Frederik Ramm <frederik at remote.org> 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ä <marko.makela at iki.fi> 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