On 11-02-13 06:15 PM, Brion Vibber wrote:
On Sun, Feb 13, 2011 at 5:49 PM, Jeroen De Dauwjeroendedauw@gmail.comwrote:
+1 to migrate to a DVCS
Unless I'm mistaken no one has actually suggested doing that.
That's been talked about a few times here already. :)
There's some notes about potential git migration plans of action at: http://www.mediawiki.org/wiki/Git_conversion
I know Avar's looked into it to various degrees, there may be some more notes sitting about. I'm definitely in favor of it getting done in some way, though there remain basic issues of what to do with extensions -- roll everything into a giant repo with core and all extensions, or do extensions separate but make it harder to maintain a full consistent versioned set?
I can definitely say that working with branching and merging in git is FANTASTIC -- especially for the ability to use source control as your workspace for in-progress patches, so you get the full benefits of versioning *and* sharing while still working on something.
-- brion
On extensions there's another idea not mentioned on that page.
Right now the distinction there is everything in one git repo vs. use git submodules.
The dilemma there is this: - In one repo everyone would need the whole history of all extensions to check out one extension, naturally this is not what we desire so we want to split it. - however if we split it then you no longer can check out all the extensions for mass development, bulk translation, etc... purposes. - so we consider having a dedicated repo which simply has git submodules to all the different extensions so you can easily check them out - unfortunately git submodules aren't like svn externals (whether svn's externals behavior could be considered a good thing all the time is a side topic) a commit id is part of the package, so you can't say "I want the latest commit from this repo", you have to say "I want <x> commit from this repo" and to get the same behavior you have to do some hacky things committing a change to the repo hosting submodule references every time the remote repo adds a new commit -- ((Although on the other hand, this could be interesting for extension branching... if we make rel1_16 style branches in the git repo they can easily target a specific commit, and "backporting" things as compatible for that rev simply means going into that branch and updating what commit the submodule refers to))
Naturally both options are not ideal. We can't have all extensions in one repo, nor is making automated commits to a repo every time a remote repo is updated an ideal.
However a key thing to note is that git submodules aren't anything really special. Sure, they're integrated into git, but the only real special feature about them is that you can target a specific commit id... and heck, we don't even want that feature, that's the whole reason it's problematic. Git submodules don't optimize cloning the repo, it doesn't store any of the remote data in the repo, so whether you use a submodule or not the actual task of getting those extension repos is still that of cloning each and every one of those remote repos individually. The only difference submodules make is that now instead of `git clone <x>` or `git pull <x>` over and over and over. You just run `git submodule <update,etc...>` and it runs the clone or pull for every repo sequentially without you having to explicitly do it. And the result is essentially the same, you end up with a bunch of git repos in subdirectories, only with the extra ability to do a batch update of them all. (Though there is a negative that when using submodules these are attached to a specific commit id and not a branch, so you can no longer decide you want to `git pull` only one of the extensions instead of all of them at once)
Hence I think there is another option. Instead of (ab)using git's submodules to reference extension repos, we could instead write a quick script that talks to a simple database or api (heck it could be a tab delimited text file committed to the git repo where the script is) which gives a list of all extension names, the url for the git repo, and optionally could even list what commit id was last used at the branch point for a release (in other words serve the same purpose as branching extensions does), while perhaps also making it easy to update what version of extensions is marked as compatible with certain releases. As a bonus; We'll retain the ability to git pull individual repos without conflicting with submodules. We can write some extra quick scripting to give us info like "These extensions are running off master, while these are running of commits tagged as compatible with a specific release". And other features we can't offer just using submodules. We also can also manage extension groups and dependencies like "AbuseFilter requires AntiSpoof" and set it up so that if you individually "./mwextension checkout AbuseFilter" it implicitly checks out AntiSpoof for you too.
Naturally it would make sense to write it in php, since MediaWiki already requires php it's the language most likely to be relevant to those checking things out. Although you could argue for users who check out onto their own machine and not onto the machine they run MW and may not have php installed. In that case you could have a case for writing it in python, since by comparison python is probably one of the most commonly installed scripting languages, and imho it's comparatively easier to install than php or ruby, or compiling something yourself in a cross-compatible way. Though on the other hand, this almost sounds like something we might make a maintenance script.
Ohh... if the translatewiki guys are looking for a dummy for streamlining support for extensions based in git in preparation for a git migration if we do so, I'd be happy to offer monaco-port up as a existing extension (well, skin) using git that could be used as a test for streamlining git support. ;) having monaco-port get proper i18n while it's still not up to a level I believe I want to commit it into svn yet wouldn't be a bad thing.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]