Using Subversion

跳转至: 导航搜索

This page only applies to developers, so if it's all Greek to you, don't worry!

Most software projects, including WordPress, use a version-control system to keep track of their source code and its revisions behind the scenes, and periodically release versions of the software for public use. Prior to the WordPress 1.5 release, the WordPress source code was stored in the CVS version-control system at Sourceforge. Since WordPress 1.5, WordPress has been using its own installation of Subversion for version control. Most WordPress users will never want to use Subversion, because they will only install the released versions of WordPress. However, developers of plugins and themes may want to test their software against the latest development version of WordPress, and people interested in Contributing to WordPress by testing or fixing bugs will also need to have access to the code that is in development.

This development code is available via Subversion. In this article, we'll cover the basics of connecting to the WordPress Subversion repository and running the commands that are available to most WordPress users.

There is also a section on Not Using Subversion, that explains how to download versions of the software without installing Subversion. You'll also want to read the section on Repository, Branches, Trunk, and Tags.

Aside from the one section on Not Using Subversion, this article assumes that you have Subversion (or at least a Subversion client) installed already, and it only covers the most basic commands. For installation instructions, alternative clients, and more detailed information, check out these resources:

Note that if you choose to use Tortoise, Subclipse, or another graphical client, the commands below will be menu selections -- however, the same principles apply. Check the help files for your client to figure out how to connect to the repository and execute the equivalent commands.

Repository, Branches, Trunk, and Tags

The basic idea of Subversion is that the source code and revisions are kept in a repository on a server. Users connect to the repository by using a client program, which allows the user to check out, view, edit, patch, and commit changes to the source code files (depending on the client's permission level; in the WordPress project, only a couple of people have permission to commit changes to the repository).

The WordPress repository is at Within the repository, there are three sections:

  • trunk: contains the latest development code
  • tags: When a version is released to the public, the source code is "tagged" with the version number. So for instance, WordPress 2.7.1 can be found at
  • branches: Sometimes when major new versions of WordPress are created, the WordPress development team makes a commitment to maintain the previous release with bug fixes (usually limited to major bugs and security issues). So, for instance, the latest development code on the 2.8 branch of WordPress can be found at

Not Using Subversion

Some people who want to test WordPress may have no interest in setting up Subversion. For those people, there are a couple of places to download development versions of WordPress:

Checking Out the Code

Once you have Subversion installed, the first step you'll need to do is to check out the code, which basically means that you will download a version from the repository to your computer. To do this, make an empty directory for your copy of the code, change to that directory, and execute the checkout command on the trunk, branch, or tag you are interested in. For instance, to check out the trunk (latest development version):

 svn co 

After a short wait (depending on your Internet connection speed), the result will be that the directory is filled with all of the WordPress files, as well as some hidden .svn sub-directories containing Subversion information.

Updating Your Copy of the Code

If some time has passed since you checked out the code, and you would like to update to the latest version now available, use the update command, after first changing to the directory where you checked out the code originally:

 svn update 

Exporting the Code

If you are not planning to do any editing, updating, hacking, or bug fixing in the WordPress code, but just want to download the latest version so you can install it somewhere, you can use the export command (after first creating a new directory to hold the results, and changing to that directory):

 svn export 

This will give you the same WordPress code as using svn co, but without the hidden .svn directories. None of the other Subversion commands will work after an export -- you need to do a checkout if you want to use the other Subversion commands.

Browsing the Code

To list all the files in the repository, without updating, checking out, etc, you can use the list command:

svn list

To list files in a sub-directory, such as wp-includes:

svn list

There is also an online browser for the WordPress Subversion repository.

Developer's commands

If you are fixing bugs in WordPress, edit the files in the directory where you checked out the code. When you are ready to submit your fixes for inclusion in an upcoming version of WordPress, read Reporting Bugs to find out how to create a bug ticket on Trac (the WordPress bug tracking system), and then use the commands below.

You may need to change to a sub-directory (such as trunk) to execute these commands.

Checking differences in your working copy

These commands help you understand what parts of your working copy are different from the committed version in the repository.

 svn status 
  • To show the changes you have made in a line-by-line patch format (which will also be used in exporting patches), use the diff command. This will output a unified diff of all the changes you have made to the entire tree of source code:
 svn diff 
  • To show the differences for just one file (multiple file paths can be given to show differences for a set of pages):
 svn diff path/to/file 

Saving patch/diff files

To share the changes you've made with other people you must export them as a .diff or .patch file (they are plain text files with the same format and either extension is fine). Once you have exported your changes as a diff file you can attach it as a patch to a Trac report.

For WordPress development all patches should be generated from the root of wordpress, rather than inside directories like wp-admin.

  • Use the diff command with > to indicate the destination file. This will save the diff output for any files changed in the current working copy.
 svn diff > my-patch-file.diff 
  • Similar to the regular diff command you can specify specific file(s) you want the diff to show differences for (useful if you have other changes in your working copy that you don't want to include in the patch)
svn diff wp-admin/comment.php wp-includes/comment.php > comments-patch-r3234.diff

Applying .patch or .diff files

  • To implement a .diff or .patch file into a working copy use the 'patch' command:
patch -p0 < /path/to/patch.diff

Reverting changes to your working copy

  • To reset your working copy to the code you checked out (to throw away any changes you've made):
svn revert . -R
  • You can also do a revert for just a single file:
svn revert path/to/file

Switching your Working copy to another branch

  • If you already have a working copy of the trunk, but you want to switch back to one of the released versions, you can use the 'svn switch' command to bring all the files in your working copy back to the state of the released version. For instance, to switch back to version 2.0:
 svn switch