Last modified: 2012-04-11 18:14:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 34138 - Stage source tree on fenari with git instead of svn
Stage source tree on fenari with git instead of svn
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Git/Gerrit (Other open bugs)
unspecified
All All
: High blocker (vote)
: ---
Assigned To: Sam Reed (reedy)
:
Depends on: 35139 35140
Blocks: 22596
  Show dependency treegraph
 
Reported: 2012-02-01 23:18 UTC by Rob Lanphier
Modified: 2012-04-11 18:14 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rob Lanphier 2012-02-01 23:18:57 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
Comment 1 Sumana Harihareswara 2012-02-24 23:13:00 UTC
Aaron, do you have time to do this?  We need it by Friday 2 March.
Comment 2 Chad H. 2012-02-24 23:29:56 UTC
(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.
Comment 3 Sam Reed (reedy) 2012-03-05 23:37:06 UTC
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
Comment 4 Chad H. 2012-03-06 00:02:38 UTC
(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.
Comment 5 Aaron Schulz 2012-03-06 00:03:38 UTC
Of course we have things like l10update and the doxygen tools that do SVN checkouts of /trunk too.
Comment 6 Sam Reed (reedy) 2012-03-06 01:53:33 UTC
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
Comment 7 Chad H. 2012-03-06 03:59:01 UTC
Full clone is about 120M.
Comment 8 Sam Reed (reedy) 2012-03-08 17:52:22 UTC
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
Comment 9 Chad H. 2012-03-08 18:20:34 UTC
(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.
Comment 10 Sumana Harihareswara 2012-03-10 02:43:31 UTC
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.
Comment 11 Sumana Harihareswara 2012-03-11 00:27:36 UTC
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?
Comment 12 Sumana Harihareswara 2012-03-12 21:14:52 UTC
OK, last thing to do: on March 21st: merge Doxygen & l10n & change how we do the source tree (correct, please, Sam).
Comment 13 Sam Reed (reedy) 2012-04-11 18:14:25 UTC
Done as of last night!

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links