Commit access

From MediaWiki.org

Jump to: navigation, search
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.

Contents

[edit] 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 and your SSH key doesn't need a passphrase, this may be an indication that your account has not been set up correctly.
  6. 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

[edit] 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.

[edit] To commit to SVN

  • 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:
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
  • Then you should get output back like this:
Sending        RELEASE-NOTES
Sending        includes/User.php
Transmitting file data ..
Committed revision 16794.
  • 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.

[edit] Some useful resources or commands

  • 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:
svn diff --revision 17109:17114
  • 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:
svn log --revision 17109:17114 --verbose
  • 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:
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 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<revision#>." in it - it autolinks the revision, and it helps us to keep track of changes related to bugs.
  • When commiting a change which fixes a bug, always include the bug number in the commit summary.

[edit] 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 update 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.

[edit] 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.

[edit] 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

[edit] 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...

[edit] Further reading

  • SVN Book - a comprehensive help resource for version control with subversion
Languages Languages: 

English  • 日本語
Retrieved from "http://www.mediawiki.org/wiki/Commit_access"
Personal tools