Last modified: 2014-09-08 11:18:40 UTC
I'd love it if, while I'm editing a particular page, and someone else commits their change to the same page before I do, some of the merging of the pages was automated, like when [[CVS]] or [[SVN]] merges changes two different people make to the same file during the same time period. I imagine that the interface would present two different diffs: a diff between the version you began editing versus the current version, then a diff between the current version versus the merger of the current version and your edited version; the text-area would contain the merged text. Differences which could not be automatically merged would be marked with something like: blah blah <MERGE-CONFLICT>blah blah===blah blah</MERGE-CONFLICT> blah And MediaWiki would refuse to accept submits of pages which contained <MERGE-CONFLICT>. When the two concurrent edits resulted in no conflicts, the page would have a message like "Someone else commited an edit while you were making your changes; please ensure that the automated merger of your two edits is acceptable". If there was a conflict in the merger, there'd be a big, blaring warning like "WARNING: Someone else commited an edit while you were making your changes, resulting in a CONFLICT. You must manually remove those conflicts". It should be easy to merge differences when two different sections were edited, and not too much harder when two different paragraphs in the same section were edited (this assumes that neither of the two concurrent edits rearranged sections or paragraphs). For changes to different sentences within the same paragaph, it's probably possible to do an automatic merge, but probably not advisable; however, we'd still want an algorithm to shrink the set of contiguous sentences or words forming the <MERGE-CONFLICT> to the smallest acceptable length. The merger of the rearrangement or sections or paragraphs is probably something we'd probably have to leave as an entirely manual process.
As of version 1.3.0 (I think; a while ago, anyway) the software *does* silently merge many edit conflicts. The conflict screen now only comes up where a complete automatic merger is not possible. However, it would indeed be nice to offer additional handling for "mixed" cases, where some "chunks" can be automatically merged, but others can't. My personal leaning would be to minimise the fine CVS-like approach as "looking too technical" for many users, and actually *grow* the conflict to the size of a section (users are already aware of headings forming sections). For instance, a revised conflict screen could say "some of your changes have been merged automatically, but those sections presented below were changed in both versions"; there would then be a series of per-section conflict boxes. The only problem is, if these were like the current one (Diff, Currentversion-textarea, Yourversion-textarea) the page could become rather long and daunting. Perhaps it would be better to just say "the software has merged some of your changes into the version shown in the upper box, but was unable to do so for others ..." and then have the same screen as usual, but with the upper textarea (currently "the current text of the article") already containing those changes which could be automatically merged. The diff would also show only those un-merged changes (i.e. it would be a diff between the content in the two textareas). Note that this shouldn't mean an automatic extra edit going through to do the partial merge, but it would mean that the default text if the user submitted without changing anything would write the partial merge to the DB [because the text written is whatever's in the upper textarea].
(In reply to comment #0) > It should be easy to merge differences when two different sections were > edited, > and not too much harder when two different paragraphs in the same section > were > edited (this assumes that neither of the two concurrent edits rearranged > sections or paragraphs). So this bug is about edits to different sections... > For changes to different sentences within the same > paragaph, it's probably possible to do an automatic merge, but probably not > advisable; however, we'd still want an algorithm to shrink the set of > contiguous > sentences or words forming the <MERGE-CONFLICT> to the smallest acceptable > length. > > The merger of the rearrangement or sections or paragraphs is probably > something > we'd probably have to leave as an entirely manual process. ...and all the rest is no good. (In reply to comment #1) > As of version 1.3.0 (I think; a while ago, anyway) the software *does* > silently > merge many edit conflicts. The conflict screen now only comes up where a > complete automatic merger is not possible. So the original summary of this bug, "CVS/SVN like merging for concurrent edits" or "edit conflict handling should offer *partial* merges where a full merge is impossible", is a WORKSFORME, and per above I'm changing it to "Automatical merge of conflicting non-section edits to different sections". > [...] Perhaps it would be better to just say "the software has merged > some of your changes into the version shown in the upper box, but was unable > to > do so for others ..." Not needed: conflicts are suppressed/merged silently when possible (cf. bug 28720). > and then have the same screen as usual, but with the > upper > textarea (currently "the current text of the article") already containing > those > changes which could be automatically merged. +1 > The diff would also show only > those > un-merged changes (i.e. it would be a diff between the content in the two > textareas). Note that this shouldn't mean an automatic extra edit going > through > to do the partial merge, but it would mean that the default text if the user > submitted without changing anything would write the partial merge to the DB > [because the text written is whatever's in the upper textarea]. Right. This would be consistent with normal edit conflict handling.
*** Bug 23736 has been marked as a duplicate of this bug. ***
Note normal conflict edit resolution doesnt care about sections... (it feeds the entire thing to gnu diff3) It sounds like what is being asked for is a nicer edit conflict screen. The current version certainly could use work.
(In reply to comment #4) > It sounds like what is being asked for is a nicer edit conflict screen. The > current version certainly could use work. Yes, that might the actual solution for the problem. Most important thing would probably be showing the user what their changes were and providing them in a way easier to paste/manually merge: (Quoting from 23736 comment #2) > (In reply to comment #1) > > (Continuing) Simply refactoring how the change conflict page is displayed > > could > > mitigate some of these issues. For example, showing the user's own diff at > > top > > would allow them to see first what exactly has occurred, and allow them to > > re-select the text to paste back into the new edit field. A particulary > > effective solution could be in printing re-opened section-edit fields rather > > than the whole page edit fields. > > Hm, this appears like bug 17177, but is actually different; in a way, it's > like > bug 980 again, in that we'd like to have a report on merge conflicts like > SVN/CVS/Git produce. > The idea was rejected by the proposer there because it would make the edit > window too complex, but maybe there's an easy solution we could still profit > from, like a way to show what your diff to the revision you were editing was, > or anyway to provide the user something better to copy and paste in the edit > area to recover the own edit. In the past I you also had the option to merge the others' edits into yours and then copy the result to the edit area, but now the textarea at bottom is read-only.
Marking as Lowest since nobody is planning to work on this currently. CCing James just in case he wants to add a VisualEditor perspective.
