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.

Kom godt i gang og etablere

 * 1) Først gør din SSH offentlige nøgle tilgængelig (hvis du ikke har en nøgle, skal du oprette en). (Ikkedin private nøgle! Må ikke dele denne med nogen!)
 * * På et Linux system, vil dette være din ~ / .ssh / id_rsa.pub fil. ( ssh-keygen-e output bedre?)
 * * På Windows, skal du generere en privat og offentlig nøgle med PuTTYGen og gemme begge filer.
 * 1) * Upload denne fil til din personlige web host (f.eks http://yoursite.domain.org/id_rsa.pub). Viser også, hvad brugernavn du foretrækker. Vi antager her, at du har valgt brugernavn er: "myUserName".
 * 2) Før du kan starte, skal du begår tilladelser hos den ledende udviklere, kan anmodninger indgives til Commit anmodninger om aktindsigt. Vær sikker på at knytte din SSH offentlige nøgle.
 * 3) Så når du har en konto, skal du følge nogle trin, før du kan begå noget. Læs først Subversion for at få et overblik over Subversion source styresystem.
 * 4) Så læs Subversion / auto-rekvisitter, og gøre præcis, hvad der står til at oprette auto-rekvisitter.
 * 5) Så kassen med svn + ssh: / / i stedet for http:// eller simpelthen ikke vil arbejde (du kan få en 403 Forbidden uventet returværdi). Det er generelt en god idé at have en anden kontrolleret-out kopi til at begå end du bruge til udvikling - dette gør det mindre sandsynligt, at du vil forvirre patches. For at gøre dette, skal du bruge: svn checkout svn + ssh: / / myUserName@svn.wikimedia.org / svnroot/mediawiki/trunk/phase3 wiki 
 * Bemærk: Hvis du bliver bedt om en adgangskode og din SSH nøgle behøver ikke et løsen, kan dette være en indikation af, at din konto ikke er sat korrekt op.Hvis du bruger Windows, skal du kontrollere, at festspil kører med din private gemt nøgle.
 * 1) Opret en UserInfo fil.
 * 2) Har en  coder linke din SVN konto til din wiki-konto, så du modtage e-mails, når nogen kommentarer til din begår. Hvis du føler dig fed, kan du i stedet bede en coder til at gøre dig en coder, og du kan derefter linke din konto dig selv på Speciel: Kode / MediaWiki / forfatter /.

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 and 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. Also, 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.
 * 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. It is in DefaultSettings.php, if you've forgotten.
 * 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. Remember that new preferences should very rarely be added.
 * Please try to use MediaWikis Coding conventions where possible. Read them every so often because they might be updated.

Forpligte sig til at SVN
cd wiki svn begå - message = "Din log besked her" includes / File-Du-Modified.php includes / anden-File-Du-Modified.php RELEASE-NOTER  ... eller hvis du foretrækker det, sætte din log-besked til en fil (f.eks .. / msg.txt fil), og brug: svn begå - fil .. / msg.txt includes / File-Du-Modified.php includes / anden-File-Du-Modified.php RELEASE-NOTER  Sender RELEASE-NOTER Sender includes / User.php Fremsendende fil data .. Engagerede revision 16.794. 
 * Første følge alt, der er anført ovenfor.
 * Så gå ind på IRC (irc.freenode.net), og / join [irc: / / irc.freenode.net / MediaWiki # MediaWiki], og vent et par minutter for at sikre, at der ikke er nogle katastrofe i øjeblikket i gang ( og hvis der er, kan nu ikke længere være det bedste tidspunkt at begå dine ændringer).
 * Så kan du begå dine ændringer. For eksempel:
 * Så skulle du få output tilbage på denne måde:
 * Så kan du lukke alle berørte bugs (hvis relevant) i bugzilla ved hjælp af en linje som "Fixed i r16794." Når du gemmer, vil din revision nummer AutoLink til SVN web interface, hvis du brugte formatet "r ####", uden mellemrum mellem bogstaver» r «og revision nummer.
 * * Code Review gør det samme, så hvis du siger "bug 123" eller "r456" i din begå besked, vil den linke dem i interfacet.


 * Så hænger rundt på # MediaWiki mindst et par minutter, så folk kan finde dig, hvis du brækkede noget.

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 (or 60, or 57, or whatever the number may be) 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.
 * When committing a change which fixes a bug, always include the bug number in the commit summary.

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.

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.

Oprettelse af en non-standard port
Tip: Kun nødvendig, hvis du bruger en ikke-standard port til SSH normalt, ellers ignorere dette. Du kan kraft SVN til at udnytte retten portnummer ved at tilføje denne til ~ / .subversion / config: [Tunneler] 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...