Git/Conversion/issues

There's a lot of folks wanting to migrate MediaWiki to git distributed source control, but there are a few issues still to sort out. This page is meant to lay out a few of those and make sure we know what needs to be done; please consider this a discussion aid, not a formal todo list.

Extensions
The main question is whether to:
 * stick core and all extensions directly in the same repository
 * bad: big repo means always big checkout -- unlike SVN can't check out just one dir
 * bad: can complicate management & dev on small subprojects (but no worse than today's SVN)
 * good: easy to set up
 * good: easy to pull updates
 * stick core in one repo and all extensions in another repo
 * almost same as first option
 * stick core in one repo and extensions in their own repos
 * good: looks nice
 * good: keeps history clean in each ext
 * bad: need to create & manage more repos (but there's infrastructure like gitorious for making farming easy)
 * bad: management is more complicated
 * bad: pulling updates from upstream to a local checkout may be more complicated
 * use git submodules
 * bad: slightly complicated
 * bad: most people don't have much experience with them, so they're a bit of a wildcard

Localization
First, a brief overview of the localization process today:


 * 1) code is checked into SVN which adds or changes localized messages
 * 2) TranslateWiki.net's automated updates import the new messages into the wiki for editing
 * 3) ... translators edit new or old messages ...
 * 4) Siebrand runs TranslateWiki.net's scripts to export localized messages back to files in the source tree
 * 5) * and may have to manually resolve conflicts
 * 6) * and may have to manually edit calling source code to correct formatting errors, misuse of options, bad description comments
 * 7) * and then commits it to upstream SVN

This process isn't inherently unfriendly to git -- it works pretty much the same way for l10n updates for StatusNet -- however the issue of may complicate this.

StatusNet's git repository today stores all plugins in the same repo as core, which behaves about the same as MediaWiki's SVN situation.

If instead we put each extension in a separate repository, then the process will need many more checkouts and more commits to run a full update on everything. Not impossible, but would at least require changes to TranslateWiki's processes to make it manageable.

Production checkouts
It's common among power users (developers and folks who like running their own sites) to run MediaWiki straight out of a SVN checkout. This has some nice benefits:
 * really easy to pull updates
 * if editing code in place, easy to commit fixes

The main 'funky' issue with SVN today is with extensions. To avoid checking out *every extension ever* you can do partial checkouts, so you tree looks like:


 * root == phase3
 * extensions/ == phase3/extensions (stub dir)
 * extensions/Foo == extensions/Foo (separate dir in same repo)
 * extensions/Bar == extensions/Bar (separate dir in same repo)

A 'svn up' from the root updates everything, but you don't need to keep around extensions you don't use.

This is harder to duplicate in a git situation with 'single repo' layout: you'd just end up with all the extensions in your dir and have to live with it.

If each extension is a separate repo, then you can check them all out in their own subdirs -- much like the SVN layout earlier -- however pulling from upstream may not happen automatically.

LocalisationUpdate extension
The LocalisationUpdate extension in particular is meant to slurp in updated localization files that have been pulled (from SVN or from git) and use their data as updates to what shipped with the current live code.

I *think* this should work the same with git as with SVN, with the caveat that automatically pulling updates may be slightly harder to automate if pulling a lot of separate repos. But it's still automatable, and the actual extension should work exactly the same.

?
Any other outstanding issues?