[OSM-dev] Auto closing of changesets in API 0.6
frederik at remote.org
Fri Oct 3 21:42:50 BST 2008
> 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...".
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev