Wikipedia talk:Edit conflicts

From Wikipedia, the free encyclopedia

Contents

[edit] Concurrent edits

When two users edit an article simultaneously and don't know about each other, it may take some work to integrate the concurrent changes. Wouldn't it be useful to have an alert "user:soandso is currently editing this page" and some means of communication so you can coordinate your work? Don't know if it's technically feasible; do others consider it desirable? Kosebamse 10:33 Mar 23, 2003 (UTC)

It is not possible to know whether another user is editing a page, because we don't have spies sitting on their desktops watching what they do. ;) The most we could know without installing spyware is whether another user has loaded the edit page or run a preview recently (ie, with an arbitrary timeout). This would be somewhat problematic for two reasons:
  • False negatives: people taking longer to make their changes than the timeout allows; end result is same as present, another user can unknowingly make an edit, and when the first guy comes back and hits save, he is informed of an edit conflict and must merge.
  • False positives: people hitting the edit link accidentally or just to copy/check out the source of a page, or starting to edit but deciding not to. (Or worse yet, misdirected web spiders hitting every edit page on the site...) Meanwhile, users will be scared off from trying to edit, and may never make that excellent, clean edit that would have taken three seconds to merge. End result: less productive activity on the wiki.
I at least don't find it a particularly good trade-off. What might be a good idea though is making a note of edit conflicts at the preview stage. --Brion 11:31 Mar 23, 2003 (UTC)

If I create a new page, and then make another edit or two, it would be nice if a flag would pop up for 5-10 minutes indicating that Im probably working on the article. Likewise, if I make a series of edits within a short time to an older page, its probably a good guess that Im making yet another edit. It would also be useful if a user who had made 10 edits to a page (without any other user making interim edits) could delete the 9 previous edits, thus making it appear as if they had only made one major edit. Susan Mason

Quite so, Susan. That last idea would be really neat, but not very practical from a software design point of view, I imagine. Since I started putting in progress in the comment field when I make the first edit of a series, and then still going (or etc.) as I go, and then done for now for the last one, I don't get nearly as many edit conflicts. Not a 100% cure of course, but worth doing. Mind you, lately I've been working on obscure articles that no-one else much edits anyway, so I guess that helps too. :) Tannin

Ideally, Wikipedia should merge the changes automatically whenever they don't genuinely conflict with each other. There are command-line tools available for this (namely diff -u and patch, which are also used by CVS I believe). This certainly can't be too hard to code? -- Timwi 17:32 26 Jun 2003 (UTC)

What Timwi suggests just above abt a year ago, or something similar, is now in effect with IIRC MediaWiki 1.3.

Nevertheless, some benefit could still be realized by warning of "genuine conflicts", i think without being subject to the objections stated above. Those of us who do big rewrites may go for an hour or more, without posting an in-use msg, repeatedly previewing, but not saving, for these reasons:

  • the in-use msg permanently complicates the history for a transient purpose;
  • and the conflicts are rare enuf that individual efforts (unneeded saves; adding & remembering to remove in-use msg; history reviews (see below)) to avoid them are disproportionate;
  • but saving more often
    • also clutters the history,
    • both saves and exposes a half-finished version that has inconsistent style and as-yet-unsatisified references (explicit or implicit) to points later in the article, and
    • (where the unfinished nature of the save fails to scream "work in progress" to an editor who's watching Recent changes) increases the chances of an edit conflict in the near future.

The measure i have in mind is

giving notice of an edit conflict in the making, whenever Bob previews a page that Alice has saved (between Bob's start of editing and the preview), instead of only when Bob actually saves.

This permits Bob to make choices, including

  • remediating the conflict immediately, instead of later on when his further editing has made the conflict more complicated, or
  • even considering the incipient conflict a warning that Alice (or Charley, who's watching Recent Changes) is likely to edit the article, with still more edit conflicts in prospect when Bob does finally save.

Admittedly, Bob can provide this service to himself by opening another window and looking at the page history periodically, but

  • it's a frustrating discipline, since it's rarely needed (i.e., better work for a computer than a person), and
  • Bob can't easily view the diffs between his unsaved draft and Alice's save, as the save-time Edit-conflict page does, and the preview-time one could.

--Jerzy(t) 17:21, 2004 Sep 4 (UTC)

[edit] Wikipedia punishes users who do large edits

I just finished editing Islam and fixing some of the dozens of typos and nonsensical sentences that permeate that article. When I submitted my changes, I was informed that someone had made an edit in the meantime, forcing me to spend another five minutes laboriously scrolling up and down, adding in my changes again. I submitted the new changes and found that someone had wiped out an entire section of the original article in the meantime. I gave up and lost all my edits.

So what are my options here? Either I can submit my changes every thirty seconds, filling up the article history with inane trivia, or wonder why Wiki isn't smart enough to combine simple changes. It could at least have some feature to save the endless scrolling up and down while reinserting my changes. -- silsor 00:16, 5 Nov 2003 (UTC)

Wikipedia is too stupid to merge changes because we don't have enough developers to have them spending time on this sort of thing. So for the time being you will have to put up with it. I should note that sometimes it is easier to merge the other person's edits into your text than to merge your edits into their text. -- Tim Starling 00:32, Nov 5, 2003 (UTC)
D'oh, I should have thought of that! From looking at the page history it looks like the other changes were just part of the edit war over a couple of links. I'll try to redo all my edits at home tonight. -- silsor
Of course it would still require some developer work, but might the merging code from an open source project like CVS be usable as a drop-in module? If it merges okay, then use the merged version; if not, then still report the edit conflict as usual. This would at least remove edit conflicts in the cases where two people are simultaneously editing completely different sections of the document. --Delirium 03:43, Nov 5, 2003 (UTC)
Merging code is similar to merging wikitext -- there are some conflicts which no computer could ever merge, specifically whenever two people edit the same thing. One difference is that CVS does a line-by-line diff, and we usually do a character-by-character (LCS-based) diff. But by all means, submit it to feature requests, if it's not already there. -- Tim Starling 04:54, Nov 5, 2003 (UTC)
There's something to be said for doing changes in more incremental steps. This makes the changelog rather easier to read and the deltas rather easier to understand (providing you do the changes in a logically partitioned fashion). So one change to fix links, another to fix grammar, another to reorder paragraphs, another to rewrite bad grammar in paragraph one - that makes (for me at least) a more legible changelog than a single megadelta that makes tweaks to every single bit of the article. -- Finlay McWalter 00:49, 5 Nov 2003 (UTC)
Finlay's advice is good. However, if you work this way, please add summaries to each of your changes so that other users can understand what you have done. And also, saving incremental changes shouldn't be a substitute for using the Preview button. There are some users who, for whatever reason, make ten, twenty edits at a time without summaries and just clog up the article history. BTW, Edit conflicts are indeed a royal PITA but they don't happen that often. Except for a few very busy pages (new and/or controversial), you should find you have most pages to yourself. -- Viajero 13:36, 5 Nov 2003 (UTC)
Nearly all of the edit conflicts I have had have been within the first ten minutes or less of the creation of a new article. It seems to be part of the current culture to make spelling corrections, add stub warnings, change formats etc etc etc in this timescale.
This can be a problem. In one recent case a newbie was making his third contribution, the first two had been good minor corrections to articles about which he was well qualified to comment, one was for his country of residence for example. His third contribution was to create a new article, again in a field of his expertise, which he wrote offline. Owing to our performance problems of the time he had trouble saving it, and on his third attempt saved instead just an external link to an information source, which is of course a sub-stub and an innocent mistake. He intended to put up the whole article as soon as he could, he'd already written it after all. Six minutes later the sub-stub was deleted. He gave up.
I have contacted this user by email and he says he will be back, fortunately he had also created a user page with an email address. The sub-stub was undeleted on someone else's protest, and is now an excellent article, but the original creator has taken no futher part in editing it, so presumably the text he wrote was wasted. The above is from his account to me, and also my perusal of article history and votes for undeletion at the time. He sees it as quite funny. But I see a problem here, which I have raised before.
Everybody acted properly and in good faith. The sub-stub met the criteria for instant deletion. Food for thought? Andrewa 15:50, 5 Nov 2003 (UTC)
Being a sub-stub alone shouldn't be sufficient to qualify for instant deletion (or VfD). Being a sub-stub that's several days old should be, naturally, as would blank, offensive, and nonsense ones, as now. To avoid our forgetting about these guys, it should be fairly simply to cook up a SQL query that selects all articles which are more than three days old and that have fewer than say 40 characters in their body. -- Finlay McWalter 17:32, 5 Nov 2003 (UTC)
It seems to me that some delay should precede action on any recently-changed page unless the edit is vandalism of some sort. Yes, a query is an excellent idea. What about an alternative version of Recent changes that only lists pages unchanged for the last 60 minutes? Keep the existing one too for the moment, although I suspect that even many vandals would be better handled using the delay.
The vast majority of the edit conflicts I have personally encountered would not even have occurred under this rule. Personally I doubt there is any really good solution to edit conflicts, so reducing their number seems a good idea. It saves the time not only of the person originally working on the article, but also of the copy-editor, sysop or whoever else currently jumps in as soon as you hit "save page".
I'm about to go away for a few days (not avoiding Wikipedia, another project). I may be ready for a go at updating the current Wikipedia:Deletion policy and some related areas when I get back, to address these issues. Or maybe someone else wants to attend to it sooner? Andrewa 00:21, 6 Nov 2003 (UTC)
You can't make changes to the deletion policy based on things like saying articles have to wait an hour or whatever before they can be deleted. Recent changes does not work this way. Unless you can come up with a solution to that, nonsense has to be deleted when it is found, which is going to be within the first few minutes of its creation. Further comments on this should go to Wikipedia talk:Deletion policy. Angela
There are several possible technical solutions, one of them I described above. An hour is modest, someone else suggested several days. The more challenging problem is the culture shift required. Please note by culture shift I don't mean challenging the underlying goals. I just mean challenging some current practices (such as the instant deletion of sub-stubs, and things that cause unnecessary edit conflicts) that perhaps don't support those goals as well as they might.
Please feel free to move this discussion to wherever it belongs. Andrewa 21:16, 6 Nov 2003 (UTC)


What I do in a case as Silsor describes, where I have been editing at several places in a page, and then got an edit conflict, is to copy-and-paste my version into the edit box, add a warning about edit conflicts in the summary, and hit save. Then afterward I check what the other person has changed, and I will encorporate his/her changes on the page again. If you have done edits at many places, such a 'reverse merge' is usually easier than a standard one. Andre Engels 21:13, 5 Nov 2003 (UTC)

See MeatBall:MergingAutomatically. Martin 20:38, 7 Nov 2003 (UTC)

I have experienced a few times the frustration of doing complicated edits only to find out I have to piece it all together again. So now when I am doing a large edit, I will first add to the top of the article "Please do not edit this page for the next 10 minutes because I am doing a large edit," then save it, and then do my large edit. It seems to work.

[edit] Edit conflicts confined to a single section

Is the software clever enough to detect whether an edit conflict is confined to a single section of an article? I ask because Dysprosia and I just clashed heads on this page whilst editing what was at that point the final section. I was explicitly editing that section, but I have no idea what Dysprosia had selected. Whatever the odds, I was presented with the entire page to sort out, just for the sake of about 10 lines at the bottom. Phil 12:06, Nov 28, 2003 (UTC)

Oh yeah, gotta love that kind of edit conflict. And currently the software is that dumb :)
Best bet is to copy an addition ready to paste back if a conflict occurs - if your changes are less monolithic then there's no other really easy way... Dysprosia 12:09, 28 Nov 2003 (UTC)
Agree. I learned during the many past times when one would save only to be told that page no longer exists. I always block and copy my additions in anticipation of something going South before the save goes through - Marshman 20:53, 28 Nov 2003 (UTC)
See MeatBall:EditConflict and MeatBall:MergingAutomatically for alternatives. See wikipedia:bug reports to suggest them to the developers. See Wikitech-l to volunteer to help develop the software. Martin 00:51, 29 Nov 2003 (UTC)


[edit] Policy on edit conflicts

mailing list post regarding the changes made to this page.

This is really a good laugh worth to be posted here. Martin writes: "I have rewritten wikipedia:edit conflicts to specifically deal with this issue. By the powers vested in me by the Wikipedia power structure, I hereby declare those changes to be de facto official, subject of course to overruling by other sysops, mailing list opinion, talk page opinion, and Jimbo's veto." Delusion of grandeur? As far as I'm aware he's an ordinary sysop, and sysops don't have a right to unilaterally write policy. --Wik 01:58, Dec 2, 2003 (UTC)
I support this policy and am therefore reverting to it until Wik can come up with some reason opposing it. Angela 02:15, 2 Dec 2003 (UTC)
I also support the policy. It seems to be basically nothing more than an expansion of what edit conflicts are and some warnings about possible problems. The only guidelines are politeness-based, and should hardly be controversial AFAICT. Tuf-Kat 02:20, Dec 2, 2003 (UTC)
I oppose it because it encourages people to override edit conflicts. Why should the one who has been overwritten have to restore his own edit again? It's punishing the victim. The one who causes a problem (even if accidental) should be responsible to rectify it. --Wik 02:22, Dec 2, 2003 (UTC)
I fail to see where it encourages people to override edit conflicts. It seems to pretty explicitly require the opposite. Tuf-Kat
It says the person who has been overwritten can't revert to his edit. So there's nothing that inhibits people from overriding edit conflicts, and let the other person sort it out. --Wik 02:32, Dec 2, 2003 (UTC)
Yes, there is something. The page clearly says "Bob should not just post his changes over the top of Alice's." Andre Engels 09:16, 2 Dec 2003 (UTC)
That sounds rather noncommittal. Why is this a "should not" and the reversion a boldfaced "must not"? Also, people can always claim it was a mistake. This will never lead to any consequences. --Wik 15:04, Dec 2, 2003 (UTC)
A person who consistently does so is certainly violating this policy. The policy protects an occasional, accidental overwriting from being reverted outright, in accordance with Wikiquette. -- Cyan 03:56, 2 Dec 2003 (UTC)

I also support this new policy. -- Cyan 03:37, 2 Dec 2003 (UTC)

I support the proposed policy too. It should be common sense that everybody just understands, but alas, WP allows in the people who failed kindergarten and were subsequently home-schooled because no one else would put up with their atrocious behavior. I wonder if Wik will accept a 100-to-1 vote, or if he will insist on being outvoted 1000-to-1. Stan 03:49, 2 Dec 2003 (UTC)

Wik, your objections are noted for the record. Nevertheless, this is now official policy. Naturally, you are welcome to protest this policy in a number of ways: you may appeal to the mailing list, to the community, to influential individuals within the community, or directly to Jimbo Wales. You may also provide arguments against the policy on this talk page, which will influence future policymakers, long after I am dead.

I have no special powers, save those I gain from the power structure, which are sufficient. If you can see why, you may yet become enlightened. Behold, thou art made whole: go and sin no more. -- Martin 18:46, 2 Dec 2003 (UTC)

I don't see what on the power structure page says you have any special powers. You have no right to set policy and I will not respect your proposal. Nor, by the way, does the mailing list have any authority. Those extra-wiki cliques, and the very idea of "influential individuals", go completely against the spirit of a cooperative project. Jimbo, of course, has the power to set strict policies, but it is up to you to appeal to him if you want your policies made official. They are not official because you say so, and I don't have to appeal to Jimbo to repeal them. --Wik 19:00, Dec 2, 2003 (UTC)
It's pretty funny to hear you use the phrase "cooperative project", considering that you personally have introduced more anger and upset into the project as a whole than any other single editor in the past month. Stan 19:33, 2 Dec 2003 (UTC)

You are quite correct that this policy is not official merely because I wrote it. Nevertheless, it is official. If you can see why, you may yet be enlightened. In the mean time, your opinion that this policy is not official is noted for the record. You may rest assured that the community does not desire that you respect its policies, merely that you follow them. Martin 19:28, 2 Dec 2003 (UTC)

I am part of the community and therefore this is not "the community's policy". And when I say I don't respect your policy, it means I won't follow it. You should really come down to Earth sometime. The policies are not made by you, nor by a small clique, but by consensus - which we quite obviously haven't got here. --Wik 19:37, Dec 2, 2003 (UTC)

Nauru Bwiema-->Talk:Nauru Bwiema

From article:

Policy from this point is not official. Bob should not just post his changes over the top of Alice's. While we accept that mistakes are occasionally made, routinely ignoring edit conflicts isn't appropriate.

So, I suppose...
The official policy is that Bob should just post his changes over the top of Alice's. Although we do not accept that mistakes are ever made, routinely ignoring edit conflicts is appropriate.
(I know this probably isn't what was intended.) Κσυπ Cyp   20:49, 2 Dec 2003 (UTC)
I suspect Wik meant to place his disclaimer in a different location, since his point of view, as expressed above, is that Bob should indeed not post his changes over the top of Alice's. I'm sure Wiki will explain if I am incorrect, though. Martin 21:54, 2 Dec 2003 (UTC)



No, my view is that this is too weak. It should say "Bob must not post his changes over the top of Alice's" etc. --Wik 22:06, Dec 2, 2003 (UTC)

The change history on this page is getting even funnier than San Serriffe! It seems that Wik's idea of "cooperation" on this edit conflict policy is to revert other people's changes over and over, hee hee... Stan 02:05, 4 Dec 2003 (UTC)

Wik, no it is not "absurd to make the language in the second case stronger than in the first." This is what started the whole thing. It is impossible to deny that it is easier to replace one word than it is to replace entire paragraphs. - Hephaestos 02:09, 4 Dec 2003 (UTC)

The quantity makes no difference. The other person can always simply revert to the version with the paragraph and then add the missing word. The point is: how can the reaction to someone's wrongdoing be worse than that person's wrongdoing itself? You could either condemn the original wrongdoing more than the reaction, or at best you can condemn both equally, but you can not possibly condemn the reaction more than the action. --Wik 02:17, Dec 4, 2003 (UTC)
Oh I certainly can. Often the first breach is by accident; a wilful reaction never is. - Hephaestos 02:39, 4 Dec 2003 (UTC)
We aren't talking about accidents but about cases where someone who must have gotten the edit conflict warning obviously ignored it and simply copied his stuff over the previous edit. --Wik 02:59, Dec 4, 2003 (UTC)
Well, what constitutes evidence that makes such an occurence obvious? It would help if you could list edits where you think this has happened to you. Then we can ask the other people involved what they experienced, and come up with guidelines that will satisfy everyone. -- Cyan 03:31, 4 Dec 2003 (UTC)
If a user gets the edit conflict screen, he can be expected to either repeat his edit on the basis of the previous user's edit, or analyze the diff and repeat the previous user's edit on the basis of his. It may be an accident if a user applies the latter method and misses a part of the previous user's edit, but if he reverts the entire previous edit, he apparently hasn't even tried. --Wik 03:48, Dec 4, 2003 (UTC)
OK, good. Now riddle me this: how do you know if the other person has even seen the edit conflict screen? Sometimes, if people goes from the edit history to the page, they might click on the wrong edit by accident, and miss the "out-of-date version" warning. This has apparently happened to you at Richard Neustadt, and I hypothesize that it happened to RickK at Bush dynasty (history now located at List of US political families), since his edit there reversing your corrections occurred over an hour after yours. If you can't be absolutely certain that the other person has seen the edit conflict screen, it seems to me that the assuming good faith fosters the best collaborative atmosphere, and a policy expressing that thought is entirely reasonable. (Of course, if a contributor is consistently overwriting others, then it becomes plausible that they're doing it deliberately, and their Wikiquette violation should be dicussed with them on their talk page.) -- Cyan 07:59, 4 Dec 2003 (UTC)
The passage that I'm trying to make as strong as the other is "However, routinely ignoring edit conflicts isn't appropriate." We aren't talking about accidents. Why is "routinely ignoring edit conflicts" merely "not appropriate", while the reversion is "absolutely not acceptable"? --Wik 23:29, Dec 4, 2003 (UTC)

If we get a problem with people routinely ignoring edit conflicts, then we can consider making the advice stronger. For now, the community is more exercised by the one problem than the other, as can be seen from discussion in a number of places. Martin 13:04, 4 Dec 2003 (UTC)

I am part of the community and I have had problems with such people. --Wik 23:29, Dec 4, 2003 (UTC)
Well Wik, from what I've seen, you haven't acted like part of the community. Instead of talking to other parties when their edits conflict with yours, you simply revert. And I've seen at least one instance when the other party has asked why you insist on reverting, you failed to answer or explain your position. IMHO, that's not very conductive to resolving edit conflicts.
Or have I simply seen a misrepresentative sample of your edits here on WP? I'd like to see an instance where you tried to work thru conflicts, & were either successful or unsuccessful. -- llywrch 01:25, 5 Dec 2003 (UTC)
Where have I not answered when asked? I've had lots of discussions about this. Yes, I reverted when someone reverted my edit first. If I accidentally revert someone, I won't mind if he reverts me either. I would recognize it was my mistake and would simply redo my edit properly, without complaining. Is it so hard to take this simple responsibility? --Wik 02:40, Dec 5, 2003 (UTC)

Wik, perhaps you could point to some examples of people who routinely and deliberately ignore edit conflicts? Martin 02:43, 6 Dec 2003 (UTC)

I don't remember all the specific cases. One example I can find is 207.179.108.132 (see history of Rusty Schweickart, where that user twice reverted my entire edit). --Wik 03:03, Dec 6, 2003 (UTC)

Seems most likely a newcomer who didn't understand the edit conflict boxes and got confused. Did you try dropping an explanation on hir user talk page? A link to this page should be sufficient, now it's been rewritten. Martin 03:16, 6 Dec 2003 (UTC)

Your double standard is now more than obvious. For the one side you always find the most far-fetched excuse, the other you want to condemn in the strongest terms. Sorry, if you want to establish that policy take it to Jimbo; until he agrees to it explicitly I will revert it. --Wik 03:23, Dec 6, 2003 (UTC)
It's hardly far-fetched to imagine that newcomers may not understand the edit conflict screen on first instance: there have been plenty of instances of confused newcomers making this kind of error. On being politely informed that they've made an error, often they change their behaviour for good, and never cause further problems. Martin 23:45, 6 Dec 2003 (UTC)
You chose to say "have I not answered when asked?" Wik, you seem to never ask before you revert, which unfortunately leads to many more angry exchanges. Could this perhaps reveal something of your temper? (Getting annoyed & not entertained over the irony of edit conflicts on this page.) -- llywrch 03:28, 6 Dec 2003 (UTC)
Again, where have I not answered when asked? You said "when the other party has asked why you insist on reverting, you failed to answer". This is not true. And I don't see what I should ask before I revert; if it's the other person's fault, it's up to him to ask if it isn't obvious to him why I revert; if he asks, I will answer. --Wik 03:32, Dec 6, 2003 (UTC)
The reason you should ask is simple. Reverting an edit without any explanation -- especially repeated reversions -- generates ill will. This leads to an edit war between you & someone else, which forces an admin to lock the article, & thus keeps anyone from making contributions -- thus generating more ill will from even more people.
Have you noticed that an awful lot of ill will has accumulated towards you here on Wikipedia? And in an environment, like Wikipedia, where consensus is essential for accomplishing anything of lasting importance, if everyone has an unfavorable opinion about you, it could be fatal to your work here. I suggest you consider ways to be more diplomatic here. -- llywrch 17:48, 6 Dec 2003 (UTC)
Reverting an edit in those cases rarely leads to an edit war, I don't think it has ever led to a page protection. And if you say reverting an edit generates ill will, why don't you condemn the one who starts it? Also, I don't see "everyone" having an unfavourable opinion about me, only those who seem to think this is a social club rather than an encyclopaedia. I'm getting along fine with those who actually want to improve articles rather than wasting time with discussions such as this one. Consensus is essential - indeed, so if you want to change the policy you'll have to convince me, otherwise there is no consensus. --Wik 18:49, Dec 6, 2003 (UTC)
As an aside, that's not true: many of our policies don't have a unanimous consensus in support - including such basic things as neutral point of view. Martin 23:17, 6 Dec 2003 (UTC)
I don't think I've ever experienced the specific case Wik is talking about, but if that had happened to me, I'm sure I would have just fixed it myself. It's not much use to blame the other person, even if it was their fault. The point is to make a good article, not get protective over your specific edits. Adam Bishop 17:57, 6 Dec 2003 (UTC)
Most likely it did happen to you, you just didn't notice it. I fixed it myself the first few times too, but it gets tiresome fast. --Wik 18:49, Dec 6, 2003 (UTC)
Wik is carefully not mentioning the situation with Danny on Sarah Edmonds, where his idea of communication was "(rv (Danny ignored edit conflict))" in his second of six reverts, and his idea of answering the question on his talk page was first to make an accusation, then to say "This is pretty clear" and a link to a diff, which was actually completely unclear, because he was objecting to a grand total of two words in the midst of two paragraphs of changes. Instead of simply saying which two words he was objecting to (two words!), he was ready to delete everybody's else work over and over until somebody (Hephaestos I think) finally guessed at what he was freaking out about. Talk about a double standard! Wik expects everybody else to work harder to make him happy, but for his part wants to be able to revert reflexively with no edit summary or talk page entry, because it's apparently too much time and trouble to communicate with the "community" he claims to be part of. Stan 19:08, 6 Dec 2003 (UTC)

What is an edit conflict? I thought that if X and Y are reverting to their versions, Z makes a non-controversial change in an undisputed section, and X reverts Z's change, while reverting Y's change, that that would be considered ignoring an edit conflict, but apparently I was wrong. So apparently I don't understand edit conflicts properly. Are edit conflicts limited to the cases, where an edit conflict screen appears? Κσυπ Cyp   21:19, 6 Dec 2003 (UTC)

New legislation enables teachers to better control the class

The senate voted 20-1 today in favour of the new legislation that should solve problems with unruly children in classes. All teachers will be equipped with nuclear warheads, for use against the kids who don't behave in class. Although there has been some criticism from fundamentalist environmentalists about the effect on the environment, and certain human rights activists have voiced their concerns, there is a general consensus that teachers should be allowed to react with nuclear retaliation against misbehaving kids. After all, noone could possibly condemn the teachers' reaction any more than the bad behaviour of the kids. Preliminary reports indicate that the new legislation is effective, as thousands of disruptive kids have already been vapourised in the resulting fireballs. Sure some may be innocent, but it's the price we must pay for justice. There have been some minor protests against the new legislation, but all the protestors were somehow vapourised. A stray nuclear missile is suspected to be the cause.

Am I the only one who finds it hilarious that there's an edit war over the page on edit conflicts? --Delirium 23:28, Dec 6, 2003 (UTC)

No, I find it quite amusing too. Martin 23:34, 6 Dec 2003 (UTC)
I guess I'm the one who gets to ruin the joke. I took one look at who's involved & protected the page. (So much for trying to be a moderator.) -- llywrch 00:31, 8 Dec 2003 (UTC)
Oops. I didn't look at the time stamps. I guess I'm just adding to the joke. -- llywrch 00:45, 8 Dec 2003 (UTC)


[edit] Undoc'd Bug or Feature in Edit-Conflict handling?

(What i've written below is long; when you get bored, consider jumping back to the top of the page, and linking via the ToC to the next item.)
This edit and this one may reflect something new, if someone was testing out relevant new code late-ish Friday UTC. Or it may have been there a while (i assume since 1.3 came on line), waiting for me to get bold in my big-page editing technique.
And in either case it may be a bug ("Wow, it never occurred to me that could result.") or a feature ("Hey, anyone pushing the envelope that far deserves something just like that happening to them."). I'll rap my own knuckles in the second case. But in either case, i'd hope we could get the danger (of unexpected and unnoticed results of saves) documented somewhere that's linked from wikipedia:edit conflicts and how-to-edit articles.
I don't know which of the following practices (or what combinations of them) occasioned the outcomes of the two edits already cited, but i'm pretty sure i engaged, during that sitting, in all of them. (I was using MS IE (v 5 or 6, i think, but ask me later, if it matters).):

  • Using "Open in New Window" (or, rather, the equivalent Shift-LMouseClick) to start one section edit on the page in question, and then using it again to start an edit of another section, before saving the first edit. (This operation "follows a link into the new window", leaving the old window as it was before linking.)
  • Using Back to get back, in the Address pane, the URL for a section edit that has been closed by a Save, calculating the change in section numbers resulting from that Save, and editing the section number (or leaving it alone, where the old section number of the first coincides with new one of the desired other section) in order to edit a different section.
  • Using File|New|Window (or, rather, the equivalent keyboard command Ctrl-N) to clone a window that displays an in-progress section-edit, and eventually doing a Save from each window. (The "cloning" creates a second window with the same URL, the same fill-ins of the form-panes, and the same Back "history" (and i suppose the same "forward history"!))

(Why would i save both clones? Don't think i set out to do that; and while i remember cloning, probably several times, only in one case do i even specifically suspect i saved both clones. The first clone (or is that called the original?) saved would be this edit and the second (the original's clone) would be one already cited: the 2nd done and 2nd cited of the edit-diffs i've cited in my first sentence of this section. Generally when i clone a window, it's either to get a new window for a search, to view a bookmarked location, etc., when i don't have a link for it that i can Open-in-New-Window via; several times in the sitting in question, it was to recover a window i wished i had Open-in-New-Window-ed from. I probably saved the "original" prematurely by hitting Enter after starting the summary for the incomplete edit, said "OK, i'll have to remember to come back and finish that when i know the page size", and (an hour later) serendipitously found i had a suitable edit for that still in progress (probably created for a purpose that i forgot to pursue). I think i realized it was a clone of one that had been saved, probably by seeing the same summary already in the page history, expected no worse outcome than an Edit Conflict screen (despite the 1st-cited unexpected result, which would have occasioned the history inspection), and proceeded to finish the edit and save.) While i don't presume i have as much insight as those who are familiar with the code, i note for developers to at least consider ruling out relevance, that one of these glitches involves adding text following section N, where replacement of section N +1 was intended (in an edit that began its life described as an edit of section N), and the other involves replacing a different section than intended, where the section numbering had also been changing.
--Jerzy(t)

So, if I understand the long explanation, you were editing a section of an article, and when you saved, the wrong section got overwritten? I believe that this is a known bug. —AlanBarrett 13:45, 5 Sep 2004 (UTC)

IMO, the above is worth documenting, along with the following.
It occurs to me that i left out one form of risky behavior, which may specifically apply to my approximately-doubled-section case. Whether or not it is functionally equivalent to cloning an edit window, i am unsure:

I may also have used Back to get to the pre-save state of already-saved edit, then changed it, rather than getting the second copy by the explicit cloning i described above. (In terms of how i work, that technique is more likely to explain that instance of that phenomenon.)

I also note that just now, i reached a point in editing where i said "Hey, if i save that, i bet i'll duplicate the other case." (The replacing-wrong-section one). Yup, i did. Scenario:

  1. Open edit of section N.
  2. Open edit of section N-M; insert one heading (presumably with or without other text); save.
  3. Save the edit of section N.
  4. The contents intended for section N replace section N-1, while section N remains unchanged.

The server's behavior corresponds to what you would expect if it is matching the section number mentioned in the section edit URL to the current section numbers, to decide what to replace with the new text. (If you can't work out your own recovery strategies, for the point where you notice you're on that road, i'll probably put some on a user page if someone asks for it.) --Jerzy(t) 20:17, 2004 Sep 7 (UTC)

[edit] Could use standard wheel rather than reinventing

Utilities such as diff3 already exist, and CVS and other revision control systems quite happily merge different edits made from a common base automatically.

Surely in most cases Bob could be presented with not just his version and Alice's version but also an automatic merge of the two with respect to the common base version? Similarly for removing vandalism that occurred other than on the latest change to an article. -- Sleepy42 12:58, 25 May 2005 (UTC)