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