https://bugzilla.wikimedia.org/show_bug.cgi?id=34580
Liangent <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #13 from Liangent <[email protected]> --- (In reply to comment #11) > 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. > If someone is expecting the fact that there is no {{cleanup}} before their edit, I believe they have downloaded wikitext (or rendered HTML) of the original version, and checked there's no existing {{cleanup}}, before submitting their edit. Now a basetimestamp which triggers edit conflict makes sense here. > > 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. > If no base revision is specified, the API module can just take the new version, re-apply appendtext or prependtext on it, then try saving again. > > (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
