>> We use a search extension, so we should not allow access to it.
>> We never have before, and it hasn't been a problem.
>
>OK, then let's wait if somebody complains ;-)

People did complain, until we *stopped* using the default MW search :)

>> Well, keep in mind that we were not using git until two weeks ago.
>
>yes, but "svn up" works the same way ;-)

I only ever used subversion for the themes and landing page, as it was a pain to use it for everything else. Seriously, git is so much better.

>> Also, there are a lot of little things that do not involve git. For
>> example, adding a banner message to LocalSettings.php or testing out
>> a new change on stage. Yes, I can use for loops, find, and sed all
>> day long (believe me, I do). However, I still have yet to find a
>> quicker and better way to keep 25+ directories in perfect sync than
>> using symbolic links. There's a reason symlinks were invented :)
>
>Indeed ;-)
>
>Symlinks have the advantage that you can update all wikis at once, and
>have the disadvantage that you must update all wikis at once ;-)

Not with my upgrade process :)

I simply check out into a new directory, switch the symlinks over one wiki at a time, and run the upgrade script for that wiki. I have it scripted, and it works quite well.

>Keeping separate checkouts for every wiki means slightly more work, but
>would allow to update or change each wiki individually.

Which is exactly what I don't want. We used to do it similar to that way, and it is a huge pain to keep track about what is different about eack wiki. Today, I can tell you that the French wiki is configured exactly the same as the English wiki, they are both the same as the Japanese wiki, and so on. I don't have to go to the wikis and do a 'git status' or anything like that to figure out how they are set up.

>>You probably already know all those arguments ;-)
>>You are doing the upgrades, so it's your choice which way you prefer.

It may not seem like it after last week, but the upgrade process itself is actually great the way it is. I can do each wiki individually, and it only takes me a few minutes to upgrade all the wikis once we decided to pull the trigger.

>> Let's all take a look at stage and see if we need to change anything
>> before we go live with it. When I deploy to prod, it will instantly
>> be out on all the wikis, and we can test everywhere out there too.
>
>http://enstage.opensuse.org/load.php?>debug=false&lang=en&modules=mediawiki.legacy.commonPrint%>2Cshared&only=styles&skin=bentofluid&*
>gives me an interesting result:
>
>exception 'DBQueryError' with message 'A database error has occurred. Did you forget to run >maintenance/update.php after upgrading? See: >http://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
>Query: SELECT md_module,md_deps FROM `module_deps` WHERE md_module IN ('mediawiki.legacy.commonPrint','mediawiki.legacy.shared') AND md_skin = 'bentofluid'
Function: ResourceLoader::preloadModuleInfo
Error: 1146 Table 'opensuse_en.module_deps' doesn't exist (hugh.provo.novell.com)
' in /srv/www/htdocs/mediawiki-1.17.0/includes/db/Database.php:781
>
>You probably need to run the database update on all stage wikis -
>destage shows the same error.
>
>Unfortunately this also blocks testing the CSS changes because the CSS
>in skins/bentofluid/ is not loaded in the *stage wikis :-(

That is a problem, as I had run the upgrade script on them. I may have to import the database from production, like I did with the other wikis. I find it a good idea to do this once in awhile anyways.