Guess Who? schreef: > just as a matter of curiosity, why do you use timestamps here, rather than > revision ids? it seems to me there would be less confusion that way: this is > the revision id for the particular version of the page I am making changes > to; if the page I try to edit has a different revision id, then clearly it's > been changed. > I didn't write the edit conflict detection code, so I don't have a definitive answer, but I'll hazard a guess. All I really know about the conflict detection code is that it's old, probably so old that it predates the existence of the revision table. Before the revision table existed, revisions were spread over two tables, the cur table for current revisions and the old table for old revisions (this is also why index.php still has the oldid and curid parameters). This is really ancient history (the revision table was introduced in MW 1.5), so I'll have to do a little guesswork here because I've only been around since 1.10 or so. My guess is that when a revision was moved from the cur table to the old table (because a newer revision was added), its ID changed. This means the revid-based approach doesn't work because revisions have two, possibly different, IDs in their lifetime (a cur_id and later an old_id) and revision IDs aren't unique (there can be two revisions with a given ID, one in the cur table and one in the old table). That's probably the reason why whoever wrote that code decided to use timestamps (again, this is just a guess). > but at any rate, let me see if I can summarize it correctly: > > 1) get the latest revision of the page, along with its timestamp > > 2) make the changes you want to make > > 3) resubmit the changed page with the timestamp you got in (1). > > a) if it matches, that means the revision you were working on is still the > latest revision, and the edit goes through > > b) if it doesn't match, some change was made to the page (or something > funky happened with the timestamp) and the server sends back an edit conflict > (or other) error. That's basically how it works, except that MediaWiki will suppress edit conflicts (i.e. let an edit through even when the timestamps don't match) in some cases. I alluded to this in an earlier message, but for clarity I compiled a list of special cases below.
* If you're creating a new article, there is no previous revision you can conflict with and the whole timestamp matching thing isn't done ** ...except when the article was deleted after the timestamp in the starttime parameter and you didn't set the recreate parameter. In practice, this means the page was deleted after you obtained the timestamp * If you're appending a new section to an article with section=new, edit conflicts are irrelevant because you wanted to append something new to the bottom anyway ** ...except when the conflicting revision was made by you and had the same summary as your edit. In this case MW assumes you (or Squid) submitted the same edit twice and throws an edit conflict anyway * If the conflicting revision was made by you, MW assumes you know what you're doing and doesn't throw an edit conflict ** ...except when the edit you're submitting is a section edit, in which case it needs to be merged (see next item) * If MW manages to merge your edit into the conflicting revision(s), the conflict is resolved and everybody is happy ** In theory, merging should succeed whenever your edit and the conflicting revision(s) don't change the same lines, but I don't know how well that works in practice Roan Kattouw (Catrope) _______________________________________________ Mediawiki-api mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
