Why is the edit conflict process so painful? When I get EC'd, it usually takes 20-30 seconds to work itself out and I typically get a JavaScript error to boot. Isn't there an easier way of handling edit conflicts that doesn't shut down a browser for up to 30 seconds on a brand new machine?
Nathan
Hmm...it may just be because I'm on cable here, that I don't ever get delayed that much. When I get ec'd, I just look at the changes, and merge them.
-Soxred93
On Feb 24, 2008, at 8:51 PM, Nathan wrote:
Why is the edit conflict process so painful? When I get EC'd, it usually takes 20-30 seconds to work itself out and I typically get a JavaScript error to boot. Isn't there an easier way of handling edit conflicts that doesn't shut down a browser for up to 30 seconds on a brand new machine?
Nathan _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Well, avoiding ANI is a great way to avoid ECs ;)
On Mon, Feb 25, 2008 at 12:24 PM, Soxred93@gmail.com soxred93@gmail.com wrote:
Hmm...it may just be because I'm on cable here, that I don't ever get delayed that much. When I get ec'd, I just look at the changes, and merge them.
-Soxred93
On Feb 24, 2008, at 8:51 PM, Nathan wrote:
Why is the edit conflict process so painful? When I get EC'd, it usually takes 20-30 seconds to work itself out and I typically get a JavaScript error to boot. Isn't there an easier way of handling edit conflicts that doesn't shut down a browser for up to 30 seconds on a brand new machine?
Nathan _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On 25/02/2008, Nathan nawrich@gmail.com wrote:
Why is the edit conflict process so painful? When I get EC'd, it usually takes 20-30 seconds to work itself out and I typically get a JavaScript error to boot. Isn't there an easier way of handling edit conflicts that doesn't shut down a browser for up to 30 seconds on a brand new machine?
What's it doing for this 20-30 seconds, and what's the error? I've never had any problems like that with edit conflicts (they're very annoying and it's takes me a while to resolve them, but my browser copes fine).
Couple stupid questions: When you get an edit conflict, why does the entire page load instead of the relevant section? Also, do .js scripts effect the speed of an edit conflict load?
Nathan
On 2/25/08, Thomas Dalton thomas.dalton@gmail.com wrote:
On 25/02/2008, Nathan nawrich@gmail.com wrote:
Why is the edit conflict process so painful? When I get EC'd, it usually takes 20-30 seconds to work itself out and I typically get a JavaScript error to boot. Isn't there an easier way of handling edit conflicts
that
doesn't shut down a browser for up to 30 seconds on a brand new
machine?
What's it doing for this 20-30 seconds, and what's the error? I've never had any problems like that with edit conflicts (they're very annoying and it's takes me a while to resolve them, but my browser copes fine).
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Because that I know of there is no current way to determine if an edit conflict is in different sections, and can be auto-merged. I would like to see an automerge feature sometime in the future, where a proposed merge is displayed. It would solve a lot of problems, even for a very conservative algorithm that only suggests a merge when the edits are done to different sections. It still would only have to load the specific section again to make the changes. I don't know how hard this would be though, but it doesn't sound too hard to me.
On Mon, Mar 17, 2008 at 6:00 PM, Nathan nawrich@gmail.com wrote:
Couple stupid questions: When you get an edit conflict, why does the entire page load instead of the relevant section? Also, do .js scripts effect the speed of an edit conflict load?
Nathan
On 2/25/08, Thomas Dalton thomas.dalton@gmail.com wrote:
On 25/02/2008, Nathan nawrich@gmail.com wrote:
Why is the edit conflict process so painful? When I get EC'd, it usually takes 20-30 seconds to work itself out and I typically get a JavaScript error to boot. Isn't there an easier way of handling edit conflicts
that
doesn't shut down a browser for up to 30 seconds on a brand new
machine?
What's it doing for this 20-30 seconds, and what's the error? I've never had any problems like that with edit conflicts (they're very annoying and it's takes me a while to resolve them, but my browser copes fine).
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On 17/03/2008, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
Because that I know of there is no current way to determine if an edit conflict is in different sections, and can be auto-merged. I would like to see an automerge feature sometime in the future, where a proposed merge is displayed. It would solve a lot of problems, even for a very conservative algorithm that only suggests a merge when the edits are done to different sections. It still would only have to load the specific section again to make the changes. I don't know how hard this would be though, but it doesn't sound too hard to me.
Conflicts are already merged automatically where possible - a more advanced system of working out how to merge (possibly involving asking the user to check it) would be great, but the very conservative algorithm you suggest does already exist.
It would be cool if it only showed, say, the surrounding two sections to fix problems with section changing/adding etc. And, even if the content can't be cleanly merged, maybe they can be displayed in the same edit box with comment tags on each end of your edit?
Nathan
On 3/17/08, Thomas Dalton thomas.dalton@gmail.com wrote:
On 17/03/2008, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
Because that I know of there is no current way to determine if an edit conflict is in different sections, and can be auto-merged. I would like to see an automerge feature sometime in the future, where a proposed merge is displayed. It would solve a lot of problems, even for a very conservative algorithm that only suggests a merge when the edits are done to different sections. It still would only have to load the specific section again to make the changes. I don't know how hard this would be though, but it doesn't sound too hard to me.
Conflicts are already merged automatically where possible - a more advanced system of working out how to merge (possibly involving asking the user to check it) would be great, but the very conservative algorithm you suggest does already exist.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
On Mon, Mar 17, 2008 at 6:25 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
On 17/03/2008, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
Because that I know of there is no current way to determine if an edit conflict is in different sections, and can be auto-merged. I would like to see an automerge feature sometime in the future, where a proposed merge is displayed. It would solve a lot of problems, even for a very conservative algorithm that only suggests a merge when the edits are done to different sections. It still would only have to load the specific section again to make the changes. I don't know how hard this would be though, but it doesn't sound too hard to me.
Conflicts are already merged automatically where possible - a more advanced system of working out how to merge (possibly involving asking the user to check it) would be great, but the very conservative algorithm you suggest does already exist.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Hm, I could have sworn I've been in such edit conflicts on ANI. If it happens again, should I file a bugreport on that?
On 17/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:
The automatic merging isn't very good, I think that's a known issue. I'm not sure how much it's meant to be able to cope with - I'll take a look at the code.
In my experience, as these things go, it's not too bad.
Automerge systems have certain largely insoluble problems- for example if two people edit the same point in a file then then they can't handle it- but there's really no way to know what the correct thing to do would be in that case; which one do you put first? In the wikipedia, particularly talk pages, people often add things in the same place, so a conflict will be flagged.
IRC it handles it if two people add something to two different parts of the same section; I don't really think you can expect much better than that.
On 17/03/2008, Ian Woollard ian.woollard@gmail.com wrote:
On 17/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:
The automatic merging isn't very good, I think that's a known issue. I'm not sure how much it's meant to be able to cope with - I'll take a look at the code.
In my experience, as these things go, it's not too bad. Automerge systems have certain largely insoluble problems- for example if two people edit the same point in a file then then they can't handle it- but there's really no way to know what the correct thing to do would be in that case; which one do you put first? In the wikipedia, particularly talk pages, people often add things in the same place, so a conflict will be flagged.
It's much better than before we had automatic merging. That was a *major* pain in the arse on any page with any degree of activity. WP:ANI is probably a good example of an automerge stress test.
- d.
On 17/03/2008, Ian Woollard ian.woollard@gmail.com wrote:
On 17/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:
The automatic merging isn't very good, I think that's a known issue. I'm not sure how much it's meant to be able to cope with - I'll take a look at the code.
In my experience, as these things go, it's not too bad.
In my experience, too. Apparently not in Martijn's though.
Date: Tue, 18 Mar 2008 00:08:48 +0000> From: thomas.dalton@gmail.com> To: wikien-l@lists.wikimedia.org> Subject: Re: [WikiEN-l] [WikiEn-l] Why do edit conflicts suck so much?> > On 17/03/2008, Ian Woollard ian.woollard@gmail.com wrote:> > On 17/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:> > > The automatic merging isn't very good, I think that's a known issue.> > > I'm not sure how much it's meant to be able to cope with - I'll take a> > > look at the code.> >> >> > In my experience, as these things go, it's not too bad.> > In my experience, too. Apparently not in Martijn's though.> > _______________________________________________> WikiEN-l mailing list> WikiEN-l@lists.wikimedia.org> To unsubscribe from this mailing list, visit:> https://lists.wikimedia.org/mailman/listinfo/wikien-l
_________________________________________________________________ �͡��ǵ��ͧ�س���� Window Live Messenger�����������ش�������ѹ��� ���!!! http://www.get.live.com/wl/all
On 17/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:
Hm, I could have sworn I've been in such edit conflicts on ANI. If it happens again, should I file a bugreport on that?
The automatic merging isn't very good, I think that's a known issue. I'm not sure how much it's meant to be able to cope with - I'll take a look at the code.
Ok, it just uses the built in merge function of the external diff program. That should be able to fix any conflict that doesn't have two people editing the same bit of the article. If you're getting conflicts with people editing different sections, there is probably something more going on. If not, then it is a bug, but not a bug with MediaWiki - seems unlikely, though.
Fair enough. Using an external engine that creates diffs and is fairly smart in merging seems indeed by far the most sensible thing to do.
On Mon, Mar 17, 2008 at 7:05 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
On 17/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:
Hm, I could have sworn I've been in such edit conflicts on ANI. If it happens again, should I file a bugreport on that?
The automatic merging isn't very good, I think that's a known issue. I'm not sure how much it's meant to be able to cope with - I'll take a look at the code.
Ok, it just uses the built in merge function of the external diff program. That should be able to fix any conflict that doesn't have two people editing the same bit of the article. If you're getting conflicts with people editing different sections, there is probably something more going on. If not, then it is a bug, but not a bug with MediaWiki - seems unlikely, though.
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l
Date: Mon, 17 Mar 2008 19:10:18 -0500> From: martijnhoekstra@gmail.com> To: wikien-l@lists.wikimedia.org> Subject: Re: [WikiEN-l] [WikiEn-l] Why do edit conflicts suck so much?> > Fair enough. Using an external engine that creates diffs and is fairly> smart in merging seems indeed by far the most sensible thing to do.> > On Mon, Mar 17, 2008 at 7:05 PM, Thomas Dalton thomas.dalton@gmail.com wrote:> > On 17/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:> > > > Hm, I could have sworn I've been in such edit conflicts on ANI. If it> > > > happens again, should I file a bugreport on that?> > >> > >> > > The automatic merging isn't very good, I think that's a known issue.> > > I'm not sure how much it's meant to be able to cope with - I'll take a> > > look at the code.> >> > Ok, it just uses the built in merge function of the external diff> > program. That should be able to fix any conflict that doesn't have two> > people editing the same bit of the article. If you're getting> > conflicts with people editing different sections, there is probably> > something more going on. If not, then it is a bug, but not a bug with> > MediaWiki - seems unlikely, though.> >> >> >> > _______________________________________________> > WikiEN-l mailing list> > WikiEN-l@lists.wikimedia.org> > To unsubscribe from this mailing list, visit:> > https://lists.wikimedia.org/mailman/listinfo/wikien-l%3E >> > _______________________________________________> WikiEN-l mailing list> WikiEN-l@lists.wikimedia.org> To unsubscribe from this mailing list, visit:> https://lists.wikimedia.org/mailman/listinfo/wikien-l
_________________________________________________________________ �Ѵ������ٻ��ء���ҡ�Թ����ſ���ͧ�س��������� Photo Gallery http://www.get.live.com/wl/all
On 18/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:
Ok, it just uses the built in merge function of the external diff program. That should be able to fix any conflict that doesn't have two people editing the same bit of the article. If you're getting conflicts with people editing different sections, there is probably something more going on. If not, then it is a bug,
Yeah, I thought that would be how it worked. The thing is diff/merge is optimised to *mostly* do the right thing, but is actually mostly optimised to work *quickly*, and so sometimes does the wrong thing, even when it could do a bit better. I've often seen diff claim that almost the whole file has changed even when there's only been a handful of scattered changes.
You wouldn't really want a better diff/merge toolset running on the wikiserver I think, because performance counts- doing a diff/merge is actually a horribly complicated process that involves comparing two (or three) long files and you can throw lots of processor power at it and get only modest improvements in the overall effectiveness and accuracy. Throwing it back to the user to do probably works better, but it is a pain.
Which is not to say that the UI couldn't help you merge stuff better.
Date: Tue, 18 Mar 2008 00:05:38 +0000> From: thomas.dalton@gmail.com> To: wikien-l@lists.wikimedia.org> Subject: Re: [WikiEN-l] [WikiEn-l] Why do edit conflicts suck so much?> > On 17/03/2008, Thomas Dalton thomas.dalton@gmail.com wrote:> > > Hm, I could have sworn I've been in such edit conflicts on ANI. If it> > > happens again, should I file a bugreport on that?> >> >> > The automatic merging isn't very good, I think that's a known issue.> > I'm not sure how much it's meant to be able to cope with - I'll take a> > look at the code.> > Ok, it just uses the built in merge function of the external diff> program. That should be able to fix any conflict that doesn't have two> people editing the same bit of the article. If you're getting> conflicts with people editing different sections, there is probably> something more going on. If not, then it is a bug, but not a bug with> MediaWiki - seems unlikely, though.> > _______________________________________________> WikiEN-l mailing list> WikiEN-l@lists.wikimedia.org> To unsubscribe from this mailing list, visit:> https://lists.wikimedia.org/mailman/listinfo/wikien-l
_________________________________________________________________ �����ٻ�ͧ�س����������Ҫվ���� Photo Gallery http://www.get.live.com/wl/all
On 17/03/2008, Nathan nawrich@gmail.com wrote:
Couple stupid questions: When you get an edit conflict, why does the entire page load instead of the relevant section?
Because section boundaries, names and numbers can change between versions. I'm not sure if there's a reason why it doesn't detect whether or not the sections have changed and only display the whole page when necessary - it may just be that no-one has written the appropriate code, yet.
Also, do .js scripts effect the speed of an edit conflict load?
No idea. I can't see why they would (not to the extent of 20-30 seconds, anyway), but there are so many scripts out there doing so many things that anything is possible.
On 25/02/2008, Nathan nawrich@gmail.com wrote:
Why is the edit conflict process so painful? When I get EC'd, it usually takes 20-30 seconds to work itself out and I typically get a JavaScript error to boot. Isn't there an easier way of handling edit conflicts that doesn't shut down a browser for up to 30 seconds on a brand new machine?
Oh I hardly notice them. I quite often just grab whatever it was I was writing and then wind back to the original page.reload and restart the edit and paste it in. Takes a few seconds but it's usually easier than using the conflict resolution page.
I've never understood why people annotate edit conflicts "(EC)" on the talk page. What is the reader supposed to do about it?
I've never understood why people annotate edit conflicts "(EC)" on the talk page. What is the reader supposed to do about it?
I only do that if my comment would seem somewhat out of place coming after the comment it conflicted with but I don't want to rewrite my comment to take the other comment into account. The most common case is simply when I conflict with someone that's saying pretty much the same thing as me. It would seem odd to just repeat what they've said as if they hadn't said it but I may still want to post my reply, for example, it may contain a bit of extra information, but I don't have the time or inclination to rewrite it to just include the parts that haven't already been said.