On 11-02-13 06:15 PM, Brion Vibber wrote:
On Sun, Feb 13, 2011 at 5:49 PM, Jeroen De
Dauw<jeroendedauw(a)gmail.com>wrote;wrote:
+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]