* Added FileJournal class to log file changes for file backends. This can be used for migrations (like moving to Swift), syncing mirror repos, consistency checks, finishing/reverting operation batches, and such. The default journal is the "null" journal, which simply does nothing.
* Added the optional schema change required for using the DBFileJournal (MySQL, SQLite).
- Update the tests to test extra characters and patterns like like \\ and $1
- Also update the tests to make sure that matches that don't have enough data to work fail
- Replace the str_replace and preg_match based code with code based on preg_replace_callback.
See discussion on r111168.
Of course no one will see warning because trunk has $wgDeprecationReleaseLimit set to 1.17 by default
(<rant>have I mentioned how I don't like that variable. People enable warnings to be *warned* about
things. Making it so people won't get warned about things until a couple months after we've decided people
should stop using function/interface/etc defeats the purpose of having warnings</rant>)
p.s. Wasn't sure if this waranted something in the release notes, I don't think it does (It's just adding a warning)
but wasn't sure.
* Added a sane default max file size to FileBackend. Operation batches need to check this before trying anything.
* Temporarily adjust the PHP execution time limit in attemptBatch() to reduce the chance of dying in the middle of it. Also added a maximum batch size limit.
* Added some code comments.
- [Actions] -
* I am aware that eventually these classes should be more than just a few lines re-directing control to WikiPage, but I'm keeping these commits as uncontroversial as possible due to feature freeze. Refactor could be done later.
* Contributes to solution of bug 27930 - Ablity to get current action (The Right Way)
* Final goal: Get the current action without needing access to Wiki.php internals (i.e. with Action::factory in one hand and an instance of IContextSource in the other)
* Required for proper fix of r108342/108343 (currently marked FIXME)
* Renamed FSFileIterator -> FSFileBackendFileList
* Renamed SwiftFileIterator -> SwiftFileBackendFileList and added it to autoloader
* A few minor doc fixes
trunk is frozen pending stabilisation so we can release MediaWiki 1.19.
Those changes introduces API changes and new SQL tables, so that sounds like
new feature we do not have time to review right now.
Please reapply changes in branches/concurrency and have code review handled
there. Once the branch has been reviewed, please hold. Once trunk is stable
enough and 1.19 got branched, you are welcome to merge the branch in trunk.
Note: we can have a Jenkins jobs setup to run the branch tests if you need.
Reverts:
r108595 r108591 r108585 r108584 108572 r108564 108560 r108559
the includes/parser/MediaWikiParserTest.php test case
* Drop now unused various test recorder options -- phpunit outputs its data in lots of machine-readable formats, use those if you need to work with
test data
* There's still a lot of duplication between NewParserTest::setUp() and MediaWikiTestCase, but hey one step at a time ;-)
* All tests pass for me (make phpunit && make parser)
* Also added FIXME about old call to bogus renameFile() function in rebuildImages.php.
* Added ContainerShardIterator class from r107980 to autoloader.
* Added a few FileBackend comments and improved FileRepo::enumFiles() comments.
Changed written by Timo and reviewed by Hashar. This should be harmless.
To enable the feature:
$wgEnableJavaScriptTest = true;
Then head to:
[[Special:JavaScriptTest/qunit]]
They were originally written for parserTests output and were in
tests/testHelpers.inc since them. Those classes can be used by most
our maintenance scripts anyway, so here is their new home.
Also make tests/testHelpers.inc a bit shorter which is always welcome.
As Brion points out in <https://bugzilla.wikimedia.org/show_bug.cgi?id=29747#c7>, the shared memory functions are very buggy. In fact, eAccelerator has disabled the shared memory functions by default for awhile now. I didn't touch APC, XCache or WinCache, but I imagine they suffer from the same problems.
* WikiPage::getParserOutput() requires a ParserOptions object (and optionally the revision ID) instead of an User object, removes an hidden dependency on $wgLang. For this reason, WikiPage::isParserCacheUsed() now also uses a ParserOptions object instead of an User object (doesn't change anything in the code except the variable name and it's not called in extensions)
* Moved PoolWorkArticleView to WikiPage.php and added an entry in the AutoLoader and moved output-related stuff directly in Article::view() so that in can be shared with WikiPage::getParserOutput() (removes code duplication, etc.)
* Added the revision ID to the PoolCounter key so that it knows which revision is being parsed and doesn't wait for another parse operation with same options but different revisions
* Removed Article::doViewParse(), Article::tryDirtyCache() and Article::getOutputFromWikitext() since they are now integrated in PoolWorkArticleView and Article::view() and there are no callers in extensions. This also fixes a bug since Article::doViewParse() will get another ParserOptions instance with special options set in Article::view() not be repercuted.
* Updated DifferenceEngine to use the new system
* Updated docs/memcached.txt to correct method names
