...

On 11.11.2011 01:00, Christian Boltz wrote: [using a SVN checkout of MediaWiki and the extensions]

...

At least not without a workaround ;-)

What about this: rename the .svn directories to .upstreamsvn and add .svn -> .upstreamsvn symlinks, but do not add the .svn symlinks to git (can git automatically ignore the symlinks named .svn in all subdirectories?)

Those symlinks would be easy to create with a script (run it on your git checkout), and are not needed on the webserver. Also renaming the .svn directories to .upstreamsvn on a fresh checkout would be easy with a script.

I just tested this - it looks like svn happily accepts the symlink and continues to work.

What do you think about this idea?

I think it sounds complicated,

Yes, but the complicated part would be done by a script (which I'll happily contribute, I expect <20 lines) + adding ".svn" to gitignore.

You/Matthew would need to run this script on the "development" machine: - after git clone to "enable" the .svn directories - same after git pull, if new directories were added by someone else - after running svn co / svn up / svn switch (if new directories were added)

Fortunately, this is not needed anymore. After Thomas explained to me how easy it was to drop the .git directory into a new installation and commit those changes, we have decided to simply use git on the openSUSE servers. I will be updating the wiki on stage using my normal workflow, but I will be pushing the new wiki core into github when I finish building it. This will let you guys modify the themes and/or extensions to work with the new MW version, and then it will let me easily move those updates to production when we feel it is fully baked. It also lets us continue with the ability to quickly checkout theme updates between releases.

...

but in the end who does the mediawiki updates decides what is the best workflow to do it. At the moment this is Matthew ;-)

I know, and I'm not too keen to take over his job ;-) (It might also be somehow problematic - even with public read access to the staging servers (thanks!) getting write/shell access for non-SUSE people might be harder.)

That is true, due to system access policies. That's the tradeoff for hosting it in the data center :)

...

For me it's important that it's documented how we do it, so that not only one person is able to do it.

Full ACK.

I'll publish a new workflow, including how it will work with git.