Page MenuHomePhabricator

Automatical merge of conflicting non-section edits to unintersecting sets of sections
Open, LowestPublic

Description

Author: matt

Description:
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.


Version: unspecified
Severity: enhancement
See Also: T6745

Details

Reference
bz980

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 7:05 PM
bzimport set Reference to bz980.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Dec 2 2004, 6:57 AM

rowan.collins wrote:

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.

Nemo_bis set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 26 2015, 8:00 AM