Last modified: 2012-04-11 18:14:25 UTC
This task is for making sure that fenari is all ready for the switch over to Git. That means: * Having the source tree available there * Having a sensible plan for decommissioning the svn directory * Making sure any local mods/hacks are actually committed * Making sure any scripts that rely on svn now rely on git
Aaron, do you have time to do this? We need it by Friday 2 March.
(In reply to comment #1) > Aaron, do you have time to do this? We need it by Friday 2 March. The scripts need to be ready by that weekend. Swapping the repo out on fenari will happen *during* that weekend.
Staging this is the easy part (just need to know the address which we need to actually checkout). We can checkout something like php-1.19git (and push to apaches), and can even selectively move wikis over one by one. Yay, het deploy. Allows us to go back and forth if necessary, rather than wiping out php-1.19 There are some live hacks that aren't committable at this point (I will have a poke around) and see what's what. Quick looks suggests we have a few other uncommitted things. Per aaron, I don't think there are (m)?any scripts that rely on like svn up/similar, though, one of the setup scripts *can* do the svn checkout, but similarly, it will continue happily if the directory already exists. So little actually has to be done there (though, it's only a changeover to git to checkout). Certainly worth a double check though. wmf-config will be staying under the private svn repo (for now at least), so nothing should need to be done there
(In reply to comment #3) > Staging this is the easy part (just need to know the address which we need to > actually checkout). We can checkout something like php-1.19git (and push to > apaches), and can even selectively move wikis over one by one. Yay, het deploy. > Allows us to go back and forth if necessary, rather than wiping out php-1.19 > That's what I was hoping \o/ > There are some live hacks that aren't committable at this point (I will have a > poke around) and see what's what. Quick looks suggests we have a few other > uncommitted things. > Let's try to get these in trunk if we can, and make a list of the remaining ones. Worst case scenario, we'll commit them to the wmf branch after the changeover. > Per aaron, I don't think there are (m)?any scripts that rely on like svn > up/similar, though, one of the setup scripts *can* do the svn checkout, but > similarly, it will continue happily if the directory already exists. So little > actually has to be done there (though, it's only a changeover to git to > checkout). Certainly worth a double check though. > Good, this is what I was afraid of mostly. > wmf-config will be staying under the private svn repo (for now at least), so > nothing should need to be done there This is actually a work-in-progress by Roan, see operations/mediawiki-config.git. But yeah, it's not a blocker to migration.
Of course we have things like l10update and the doxygen tools that do SVN checkouts of /trunk too.
Chad, how much space is a git clone/checkout of 1.19wmf1 and wmf extensions going to take on disk? ie the actual files and also the history metadata etc etc Need to make sure by doing this we aren't going to cause issues on most of the Apaches. If it will, this needs rectifying soon, whether just moving stuff around, or even to the extreme of prioritising a full rebuild of the apaches with a better disk layout
Full clone is about 120M.
Doxygen (svn.wikimedia.org/doc) on formey * Needs manual git checkout, and crontab svn up conversion manifests/svn.pp - Line 91 "svn up" -> "git pull" svn users - What are we doing here? Are we keeping USERINFO? Extension Distributor * bug 27812 Deployment * git checkout to php-1.19git * Push to apaches l10update * Needs manual git checkout * Update l10nupdate-1 Line 12, 19 svn up -> git pull Need to fix/properly setup my puppet git checkout so I can start fixing these and committing the fixes for review
(In reply to comment #8) > Doxygen (svn.wikimedia.org/doc) on formey > * Needs manual git checkout, and crontab svn up conversion > > manifests/svn.pp - Line 91 "svn up" -> "git pull" > Should be pretty trivial. > svn users - What are we doing here? Are we keeping USERINFO? > I think we should just pull the name/email/etc straight from LDAP and kill USERINFO entirely. > l10update > * Needs manual git checkout > * Update l10nupdate-1 > Line 12, 19 svn up -> git pull > Already has a change pending in gerrit, waiting for merge after the conversion.
Sam has told me that it looks like we need no further preparation before the March 21st conversion; if that's wrong, please speak up now.
Chad said that fenari is almost ready; 1 ops-related maintenance script depends on SVN, and the rest is repo-agnostic. Is this the case? What is that last ops-related script?
OK, last thing to do: on March 21st: merge Doxygen & l10n & change how we do the source tree (correct, please, Sam).
Done as of last night!
