https://bugzilla.wikimedia.org/show_bug.cgi?id=34580
Brad Jorsch <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WONTFIX --- Comment #11 from Brad Jorsch <[email protected]> --- Appending and prepending text absolutely *should* throw edit conflicts. If two people try to prepend text at the same time, you cannot assume that "A B orig" (or "B A orig") is what either of them might have intended any more than you can assume that edits "orig1 A orig2" and "orig1 B orig2" should result in "orig1 A B orig2". Consider for a particularly silly example where one person from the US prepends "{{cleanup|reason=The article is demonizing the subject}}" and one from the UK prepends "{{cleanup|reason=The article is demonising the subject}}". You'd end up with two tags at the top of the article saying effectively the same thing. Real-life cases aren't usually this clearly ridiculous, but they occur often enough that were this bug fixed we'd certainly start to get bugs that edit conflicts were not being raised when people try to append or prepend the same thing at the same time. And that would be more hassle to clean up, because someone has to notice and then make a third edit to merge things. New sections on talk pages are the one exception to this, which is already filed as bug 22783. Thus, I'm going to close this as WONTFIX. Also, for background: An edit conflict happens any time that the submitted basetimestamp (wpEdittime in the GUI) is not the same as the timestamp on the most recent revision of the article. Every single time. But sometimes the conflict can be automatically resolved, if the changes from base→current and base→submitted can be merged. Improving this automatic edit conflict resolution is outside the scope of a bug against the API, and it would not surprise me if a bug about that already exists. The API's appendtext and prependtext take the existing page content, append/prepend the text, and then treat it as if it were an edit of the entire page. This is the only way it can work until someone rewrites EditPage, which is also outside the scope of a bug against the API. This is also how section editing (particularly section=new) works, which is probably why Nemo marked this as a duplicate of the new-section bug. (In reply to comment #7) > We had edit conflicts at Commons even when no timestamp was set. > "listRequestSubpage" and "notifyUploaders" never set a timestamp. There are various possibilities for that. For example, if someone else's edit gets saved in between when ApiEditPage chooses a default basetimestamp for you and when EditPage actually checks for an edit conflict, that could do it. This could be more likely if ApiEditPage fetched that default basetimestamp from a lagged slave. (In reply to comment #4) > The general fix for all these edit conflicts is to write a variation of the > GNU diff3 file-merge program Feel free to do so. Or hire someone to do it for you, if you lack the necessary skills. Or convince someone else that they should pay someone to do it for you. What's not going to get it done is just asserting that "someone" should do it in every tangentially-related discussion. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
