The loss of specific names would create a visible name conflict; when you've got "MySQL.php" open, what the hell is it? Is it the DatabaseMySQL class? Some other random MySQL-related thing? Update.php is also confusing -- we have an update.php which is a command-line script.
Don't do these confusing names; there's no pressing functional need to move the files at all, but if you must move them at least keep their distinct names so I can find my code.
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
* Add @addtogroup tags to various classes, to try and group conceptually-related classes together.
* Add brief descriptions to various Special pages, thanks to Phil Boswell.
* Moving some docs to be right above the classes they represent, so that they are picked up.
* remove require_once() throughout whole code, yet left in few places
* move global functions in HttpUtils, ProxyTools, Credits to class methods
* php5 only: __autoload() now used, combined with class->file map and require()
* move initialization of $wgValidSkinNames to Skin::getSkinNames()
* few more changes that will surely break stuff.
These tail-anchored regexps are insanely slow. The worst case comes
when Japanese or Chinese text (ie, no word spacing) is written on
a wiki configured for Western UTF-8 mode: the Unicode characters are
expanded to hex codes and the "words" are very long paragraph-length
monstrosities. On a large page the previous regexps may take over 20
seconds *each* on a 1GHz-level processor on such pages of non-trivial
length...
The reversed versions which are consistently much faster, for instance
by a factor of 10000 for the pathological case and a factor of 10 for
more typical English-style pages.
* DB_WRITE now called DB_MASTER, DB_READ now called DB_SLAVE
* Converted to use SQL wrapper functions instead of direct SQL in various places
* Experimental method for preserving the chronological order of events when slave servers are used. Untested.
* Fixes to the new post-parse existence test feature
* Some.. other stuff
