Last modified: 2014-09-08 11:18:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 980 - Automatical merge of conflicting non-section edits to unintersecting sets of sections
Automatical merge of conflicting non-section edits to unintersecting sets of ...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 23736 (view as bug list)
Depends on:
Blocks: section-editing
  Show dependency treegraph
 
Reported: 2004-12-02 06:57 UTC by Khym Chanur
Modified: 2014-09-08 11:18 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Khym Chanur 2004-12-02 06:57:26 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.
Comment 1 Rowan Collins [IMSoP] 2004-12-02 16:55:18 UTC
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].
Comment 2 Nemo 2013-03-06 08:44:01 UTC
(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.
Comment 3 Nemo 2013-03-06 10:08:44 UTC
*** Bug 23736 has been marked as a duplicate of this bug. ***
Comment 4 Bawolff (Brian Wolff) 2013-03-07 01:20:54 UTC
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.
Comment 5 Nemo 2013-03-07 06:55:29 UTC
(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.
Comment 6 Quim Gil 2014-04-25 03:37:49 UTC
Marking as Lowest since nobody is planning to work on this currently.

CCing James just in case he wants to add a VisualEditor perspective.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links