Page MenuHomePhabricator

Exploration: What data do we have to decide if a conflict can be resolved?
Closed, ResolvedPublic3 Estimated Story Points

Description

The decision if an edit is a conflict or not is done in MediaWiki core and doesn't have anything to do with the extension. The task is to understand what information core provides about the conflict. Is it even possible for the extension to understand if a conflict can automatically be resolved, and how?

What we would need is a decision like "two conflicting edits have been made, both adding new text at the exact same position, without touching any existing text". Is this possible?

Event Timeline

Restricted Application added a project: TCB-Team. · View Herald TranscriptDec 4 2019, 10:18 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
WMDE-Fisch set the point value for this task to 3.Dec 11 2019, 12:42 PM

The plan to suggest a automatic resolution would be the following:

  • on a talk page on an edit conflict
  • create a diff between the base version and the conflicting version
  • create a diff between the base version and your version
  • if both diffs contain one addition on the same line and nothing else, they could be auto merged by putting the newer addition underneath the older one

The plan to suggest a automatic resolution would be the following:

  • on a talk page on an edit conflict

We are given the Title of the page and can extract the Namespace

  • create a diff between the base version and the conflicting version
  • create a diff between the base version and your version

We have access to the EditPage so we can extract the base version from it and calculate the diffs above using TwoColConflict's SplitConflictMerger

  • if both diffs contain one addition on the same line and nothing else, they could be auto merged by putting the newer addition underneath the older one
awight added a subscriber: awight.Dec 18 2019, 2:24 PM

We also have access to the new, unsaved revision text.

If the edit is happening in a section, we have the section identifier.

As can be seen in patch https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/530148/ , if we hook in after the external 3-way merge tool, we can detect whether automatic resolution failed.

As can be seen in patch https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/530148/ , if we hook in after the external 3-way merge tool, we can detect whether automatic resolution failed.

Introducing a new hook in the edit page in core would be another idea. But I think, acting exclusively in the existing code of the extension gives us everything needed. It's not necessarily important to know, if a previous three way merge failed or not.

In TwoColConf, we're at a point where there's clear that every (core-) attempt failed to resolve the issue and we can go our own way from there. It's just another special case with it's own little workflow there.

thiemowmde closed this task as Resolved.Jan 8 2020, 11:02 AM
thiemowmde moved this task from Review to Done on the WMDE-QWERTY-Sprint-2019-12-11 board.

The relevant line of code in the existing code is where a new \Diff() is created and processed in LineBasedUnifiedDiffFormatter::format(). The detection algorithm would do something very similar:

  • Create two of these Diff objects, one from the base to the first edit, another one from the same base to the conflicting edit.
  • Compare the two Diff. Both must start with a "copy" block that does have the exact same content (same number of lines), followed by an "add" block (doesn't matter how long it is), followed by another "copy" block (must be identical again).

That should be it. We just shared what we learned in person within the WMDE-Technical-Wishes-Team and consider this exploration done.

Further note:

  • We should check if the two Diff are 100% identical (both try to add the exact same text in the exact same position). If this is true, we might even be able to just throw the later edit away.
  • However, because ~~~~ is a preprocessor feature, the two edits might show a different timestamp. Is there a way to detect this? Should we care?