Since there are some talks about migration from SVN anyway[1], I decided to unshelf my essay on this matter.[2] It discusses possible alternatives to Subversion and is in no way complete, everyone is invited to participate in drafting and discussing. Some sections need input of those who have practical experience with those systems, as for example I've never used Bazaar.
------ [1] http://www.mediawiki.org/w/index.php?curid=44222&diff=301482&oldid=3... [2] http://www.mediawiki.org/wiki/Source_control_considerations
I believe we've had two discussions in the past on switching to git.
I talked to Tim about various other advantages of .git, like the lack of autoprops annoyance, and corrected the notion that there isn't a Windows client and his reponse was "maybe in a year or two".
Generally the limitation is the fact that we're currently abusing svn's ability to only check out specific directories rather than an entire repo to make it easy to check out all the extensions or individual ones without any trouble. We've had ideas like using git submodules to mark stable versions of extensions so extension repos can be flexibly checked out.
Oh something interesting. With a bit of trickery I recently managed to splice the entire history of one git repo into a branch of another git repo creating a git repo that has two separate initial commits in two separate branches. And from the looks of it it's perfectly possible to fetch history from the original repo into the proper branch. So it should be interestingly possible to create a script that fetches history updates for every extension at once by embedding them all into separate branches of a single git repo, and then locally (with no network latency) pulling the history from those branches into the real repos.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Max Semenik wrote:
Since there are some talks about migration from SVN anyway[1], I decided to unshelf my essay on this matter.[2] It discusses possible alternatives to Subversion and is in no way complete, everyone is invited to participate in drafting and discussing. Some sections need input of those who have practical experience with those systems, as for example I've never used Bazaar.
[1] http://www.mediawiki.org/w/index.php?curid=44222&diff=301482&oldid=3... [2] http://www.mediawiki.org/wiki/Source_control_considerations
On Sat, Feb 6, 2010 at 21:13, Daniel Friesen lists@nadir-seen-fire.com wrote:
I believe we've had two discussions in the past on switching to git.
I talked to Tim about various other advantages of .git, like the lack of autoprops annoyance, and corrected the notion that there isn't a Windows client and his reponse was "maybe in a year or two".
Generally the limitation is the fact that we're currently abusing svn's ability to only check out specific directories rather than an entire repo to make it easy to check out all the extensions or individual ones without any trouble. We've had ideas like using git submodules to mark stable versions of extensions so extension repos can be flexibly checked out.
Oh something interesting. With a bit of trickery I recently managed to splice the entire history of one git repo into a branch of another git repo creating a git repo that has two separate initial commits in two separate branches. And from the looks of it it's perfectly possible to fetch history from the original repo into the proper branch. So it should be interestingly possible to create a script that fetches history updates for every extension at once by embedding them all into separate branches of a single git repo, and then locally (with no network latency) pulling the history from those branches into the real repos.
It's interesting that the #1 con against Git in that document is "Lots of annoying Git/Linux fanboys".
I guess this is as good a time as any to plug the git-svn notes I scribbled down yesterday: http://www.mediawiki.org/wiki/Git
In order to convert to Git it would help to collect a list of things that should be split into separate repositories:
* /USERINFO, /civicrm and /wikimedia-web * Everything in /trunk/* * Additionally /trunk/extensions/* and maybe some /trunk/tools/*
That should yield around 500 repositories. That might sound crazy but best practice for any distributed version control system is that repositories should be split at the boundaries at which code doesn't pass over, and when's the last time /trunk/FOO shared some code with /trunk/extensions/BAR for instance?
And if someone really wants to check out all 430 extensions that's easy enough with an "extensions" project with 430 submodules, but the most common case should be someone checking out MediaWiki.git + 3-5 extensions.
I'm doing some experiments with splitting up MediaWiki's Git mirror[1] using git-filter-branch[2]. It takes a *long* time with this huge repository but a working conversion is the fastest way to get people on board.
Of course this is a great chance to clean up some aspects of the repository, such as:
* Rewrite the commits to give everyone real names / emails, like Tim Starling / tstarling@wikimedia.org instead of tstarling. This can be done automatically by parsing the USERINFO files & adding to them where appropriate. * Combine users like magnusmanske and magnus_manske into one * Rename/drop branches/tags if someone wants that
1. http://gitorious.org/mediawiki-svn-mirror 2. http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-...
On Sun, Feb 7, 2010 at 00:38, Ævar Arnfjörð Bjarmason avarab@gmail.com wrote:
It's interesting that the #1 con against Git in that document is "Lots of annoying Git/Linux fanboys".
No, it's the "screaming 'hell yeah!' but have no idea what they're talking about" part. :-)
g
wikitech-l@lists.wikimedia.org