https://bugzilla.wikimedia.org/show_bug.cgi?id=25598
Summary: Allowing merging when external diff3 is unavailable
Product: MediaWiki
Version: 1.16.0
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: History/Diffs
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: furry...@gmail.com
Created attachment 7742
--> https://bugzilla.wikimedia.org/attachment.cgi?id=7742
Patch to GlobalFunctions.php (1.16.0 version) to allow use of PEAR's
Text_Diff_ThreeWay class
Some hosts, especially shared hosts such as nearlyfreespeech.net, support
MediaWiki, but do not support calling external programs such as diff3. The
current behavior when diff3 is unavailable is to fall back on the old behavior
of signaling a conflict edit whenever two people edit the same page, even if
they edit completely different parts of the page using section edits. This can
also happen with one user and multiple browser tabs -- I've been bitten this
way, and it's a bit annoying. Hence, I've developed a proof-of-concept patch
for using PEAR's Text_Diff_ThreeWay class when $wgDiff3 is empty. (The patch is
for includes/GlobalFunctions.php in 1.16.0 sources, because that's the version
I tested it on.)
There are some problems with the patch in its current incarnation.
* It uses PEAR, whereas, if I'm not mistaken, no other MediaWiki code uses
PEAR. (However, there's still no dependency on PEAR if you do use an external
diff3, and you can still fall back on the current behavior if PEAR is not
available.)
* The code misuses the Text_Diff_ThreeWay class by reading one of its private
variables (to check if there were any conflicts). There are no current
practical workarounds that I can find.
* Very minor: The code could stop when it finds the first conflict, since that
already invalidates the merge, but instead continues processing the entire text
block. (I imagine the behavior with an external diff3 is similar, but hey, an
optimization is an optimization.)
* The inputs need to be exploded (using PHP's explode() function) into multiple
strings (one per line) and the output needs to be imploded into one string
afterward, which is inefficient.
All of these can be resolved by adapting the library's source (which is LGPL)
into MediaWiki itself and modifying it as necessary (though fixing the last may
be nontrivial; I haven't checked), but I thought I'd rather float the idea here
before trying it. (Also, if somebody wants to volunteer to do this for me, by
all means... ;))
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
