[OSM-dev] Auto closing of changesets in API 0.6

Frederik Ramm frederik at remote.org
Fri Oct 3 21:42:50 BST 2008


Hi,

80n wrote:
>     I'm also in the "I don't want a changeset to go on forever" camp. If
>     the edit is so complex that it cannot be commited within a few hours
>     then it should not be one changeset.
> 
> So, implement this in the client. 
> The server doesn't *need* to enforce it.

My plan was to reject any database change in the API if it is associated 
with an expired changeset and I still think this is the way to go.

It is true that the server doesn't *need* to enforce it but then the 
server doesn't *need* to support changesets at all - it is us who decide 
that we want to have them, and we want to have them for a purpose.

Enforcing the expiry or closing of changesets gives us the chance to 
know for sure that certain changesets - most, actually - are "complete" 
and will not change anymore; you can then say for sure: "user so-and-so 
made the following changes in changeset so-and-so". You can use software 
to revert a changeset without running the danger that between your 
examining the change and your command to revert it, the author has added 
stuff to it.

If you intend to make it possible that changesets go on forever, the 
next logical thing would be to have a versioning for changesets ;-) "in 
yesterday's version of the 'fixing london' changeset, user 80n had done 
the following 283 edits; today's version has another 35 edits added...".

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"




More information about the dev mailing list