Developer account/Subversion


 * This follows on from How to become a MediaWiki hacker.
 * The Subversion page may also be useful.

This page provides a quick overview of useful things to know when starting out with MediaWiki commit access. If there is something that you find useful, and which is not shown on this page, then please add it.

Getting Started and set up

 * 1) First, you need commit permissions from the lead developers.
 * 2) Then make your SSH public key available. On a Linux system, this will be your ~/.ssh/id_rsa.pub file. For example, upload this file to your personal web host, and send your URL to the person setting up your account (e.g. http://yoursite.domain.org/id_rsa.pub ). Also indicate what username you would prefer. We'll assume here that your chosen username is: "myUserName".
 * 3) Then when you have an account, you need to follow some steps before you can commit anything. First read Subversion to get an overview of the Subversion source control system.
 * 4) Then read Subversion/auto-props, and do exactly what it says to set up auto-props.
 * 5) Then checkout using svn+ssh:// instead of http://, or it simply won't work. It's, generally speaking, a good idea to have a different checked-out copy for committing than you use for development - this makes it less likely that you'll confuse patches. To do this, use: svn checkout svn+ssh://myUserName@svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 wiki
 * Note: If you are prompted for a password, this may be an indication that your account has not been set up correctly.
 * 1) Create a USERINFO file, with your name and if possible email address, so that other developers can get in contact with you. This file is used to generate the list at http://svn.wikimedia.org/users.php

Guidelines for Applying Patches
cd maintenance php parserTests.php --quiet --quick --color=no ... and compare the failures before with the failures after, to check that there were no regressions.
 * Remember that trunk is supposed to be live code -- keeping things up to date and ready to run at all times is our biggest method of quality control. Code must work at all times, except of course when it's broken by accident.
 * Always update the RELEASE-NOTES file if you fix a bug in bugzilla, or make a non-trivial change. This also applies to any changes that are visible to the end-user. This also applies to any significant architectural changes or rewrites (even if not user visible), where those changes will impact third party extensions. By convention, changes are added chronologically to the end of the RELEASE-NOTES.
 * Consider possible security implications (e.g see this security note for extension authors).
 * Do not backport any new features to the stable trunk without prior permission. In fact, best to just leave the stable trunk alone. Leave all backporting of fixes to the release manager, and save yourself grief. Things should only be backported if they are a security fix, or are vital for the software to run. New features don't go into maintenance releases of old versions.
 * Don't touch the release tags at all. Ever.
 * Try not to break things, or people may get cranky. For example, if you are changing the parser, you can run parserTests before and after to help determine if your change introduced any new breakages, like so:
 * Test all patches thoroughly before applying them to SVN HEAD.
 * Do development in a different folder, and then use svn revert -R . in your commit copy before you apply any patches from development. This makes mixing patches together less likely.
 * Try not to make any big changes right before the tree is branched into a stable release (this currently happens once every 3 months).
 * If you're the very first person updating the RELEASE-NOTES after a stable release (i.e. at the start of the new cycle), the procedure is to move the changelog entries (e.g. the "changes since 1.7" bit) from the RELEASE-NOTES file into the HISTORY file. Once it has been moved there it can then be deleted from the RELEASE-NOTES file, and a new section started (e.g. "changes since 1.8").
 * Remember to bump the $wgStyleVersion number on any updates to any .CSS or .JS files.
 * Try not to reuse variables, and make messages easy to grep for.
 * Try not to use boolean parameters where the meaning may be unclear later - use class constants with descriptive names instead.
 * You should try to mark any new functions or variables as private, public, or protected as appropriate.
 * If you add a new hook, you need to update docs/hooks.txt with the name of the hook, a description of what the hook does, and the parameters used by the hook. It should also be included at the bottom of the "new features" section of the RELEASE-NOTES.
 * Use the WebRequest class, rather than $_GET or $_POST.
 * Try to avoid introducing new preferences, if possible, by supplying sane defaults. New preferences should very rarely be added.

To commit to SVN
cd wiki svn commit --message="Your log message here" includes/File-You-Modified.php includes/Another-File-You-Modified.php RELEASE-NOTES ... or if you prefer, put your log message into a file (such as the ../msg.txt file), and use: svn commit --file ../msg.txt includes/File-You-Modified.php includes/Another-File-You-Modified.php RELEASE-NOTES Sending       RELEASE-NOTES Sending       includes/User.php Transmitting file data .. Committed revision 16794.
 * First follow everything listed above.
 * Then go onto IRC (irc.freenode.net), and /join #mediawiki, and wait a few minutes to ensure that there isn't some disaster currently in progress (and if there is, now might not be the best time to commit your changes).
 * Then you can commit your changes. For example:
 * Then you should get output back like this:
 * Then you can close any affected bugs (if applicable) in bugzilla, using a line like "Fixed in r16794." After you save, your revision number will autolink to the SVN web interface, if you used the format "r####", with no space between the lower case 'r' and the revision number.
 * Then hang around on #mediawiki for at least a few minutes, so that people can find you in case you broke anything.

Some useful resources or commands
svn diff --revision 17109:17114 svn log --revision 17109:17114 --verbose svn merge -r REVISION_NUM_YOU_WANT_TO_UNDO:REVISION_NUM_TO_REVERT_TO. svn status svn diff svn commit --message="Self-revert accidental breakage" includes/file-you-changed.php includes/another-file-you-changed.php
 * To see what changed in a particular revision number, go to http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=16789 and replace the revision number in the URL as appropriate.
 * The "svn status" command will show you any files that differ between your local version and the central version.
 * The "svn diff includes/file_you_changed.php" command will show what exactly has been changed in a certain file, relative to the last checked out version.
 * If you want to see what changed between two revisions from the command line, you can use this command:
 * You should probably subscribe to the wikitech mailing list.
 * If you want to see what's changed recently, you can use the CVS mailing list.
 * Sometimes there is a small bit of lag between commits, and getting notified via CVS email. There is no lag however with SVN, so to see what's changed recently, or even not-so-recently, you can use the "svn log" command. For example this will show all changes between the specified revision numbers, and details of which files were changed:
 * You can always ask questions on the #mediawiki IRC channel. Also if the CIA-7 bot is working, it will print out notifications of SVN commits to the #mediawiki channel as they happen.
 * If you commit a change, and it turns out to be completely broken, then you can revert it by doing something like this:
 * To view a specific bug in bugzilla, go to http://bugzilla.wikimedia.org/show_bug.cgi?id=1234 and replace the bug number in the URL as appropriate.
 * When closing a bug in bugzilla, include a comment with something like "Fixed in r." in it - it autolinks the revision, and it helps us to keep track of changes related to bugs.

Going live
Code in Subversion won't immediately be live on Wikimedia wikis like Wikipedia. This is to avoid immediate breakage of the sites and to allow for code review to take place.

When a system administrator (typically Brion Vibber or Tim Starling in this case) has reviewed code changes, they will perform a standard svn up on the production cluster. At this point, changes are live on http://test.wikipedia.org, and last-minute checking can be done to ensure nothing has been broken under Wikimedia's idiosyncratic configuration.

If everything appears okay, then changes will be synchronised to application servers. This is also known as "scapping", after the "scap" script which does this.

To find out who last modified a particular line of code
Run a command like this (using the includes/Parser.php file as an example) : svn blame includes/Parser.php | less ... and then search for the line by typing "/" + your search term (e.g. the function name). It may take about 20 seconds for the svn blame output to be generated.

This will show which revision a line was modified in, and by whom, like so:

4452     timwi     $argc = count($args); 9860 kateturner 4452     timwi     for ( $i = 0; $i < $argc-1; $i++ ) { 4904    hashar          if ( substr_count ( $args[$i],  ) != substr_count ( $args[$i],  ) ) { 4904    hashar                $args[$i] .= '|'.$args[$i+1];

... you can then look up that particular revision number using the SVN web interface, to see what the commit log message was to get an explanation of why a change was made. If necessary, you can then ask the user; there is a list of SVN committers in the SVN server with contact information.

Setting up a non-standard port
Tip: Only needed if you use a non-standard port for SSH normally, otherwise ignore this. You can force SVN to use the right port number by adding this to ~/.subversion/config : [tunnels] ssh = $SVN_SSH ssh -p 22

Branching and merging
You may wish to do ongoing experimental work in a branch, so that the development trunk remains stable until your change is ready to merge. Branches are also used for the quarterly releases, so that additional bug fix releases can be made easily.

See the Subversion/branching guide for more...