On Fri, May 16, 2008 at 10:13 AM, Dair Grant <[EMAIL PROTECTED]> wrote: > Frederik Ramm wrote: > >>> First of you might want to do rollback from Z to Y only because >>> you want to keep Y to X. >> >> Changesets are a grouping of edits that make things easier because one >> only has to work with the groups - e.g. not show all individual edits, >> but show the group as a whole, etc. > > That is really the core idea of a changeset; it deals with a collection of > changes as one entity. > > If an editor wants to be able to revert/have a check in comment for/etc > individual changes, they can just commit each change in its own changeset. > > Looking at how this model is used elsewhere (any source control system), > that'd be like committing after each keystroke/newline. I doubt that would > be useful - the thing changesets bring is the ability to record why some > changes were done as a whole.
For most rcs systems such changes actually are atomic though, and don't allow multiple edits per changeset. We really have to support that if we're to keep Potlatch and the possibility of live editing systems, and still maintain a sensible number of useful changesets. > > > I.e., if you look back at some old data you want to see that user X's > Saturday morning contribution was "added road names based on NPE map". > > Being able to see "user changed tag X to Y, user dragged node here, user > changed tag Y back to X, user changed tag X to Z" is not useful; it's just > information for the sake of it. > > If an editor wants to monitor individual edits in order to provide coaching > or feedback to users, that's best done by watching user actions as they > happen and providing feedback based on that (recording that info in the DB > for every action for every user is pointless, as who would ever really go > back and process it?). We already do store this information if they're using Potlatch. If they're using an editor with a "save" concept then obviously not. Is it useful? Probably not most of the time. > >> You want changesets as some universal access and documentation method >> for the history of everything, and I want them as closed, near-atomic >> changes. > > +1 to the latter; changesets let us group related changes together, and > document what they were for - that's the point of having them. > Which comes down to how these changesets are actually being implemented in the server. I was under the impression that it was just a changeset ID column added to the node/way/relation history tables that could then be used to query what changes happened for a particular changeset. In this model we already have the detailed information, and this whole argument is over the format of a changeset query where it would be quite possible to implement it both ways, and have both available at the same time. Of course if it's intended to collapse changesets as they are created, then that's a different matter. Dave _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
