Customized WordPress: Setting up an SVN Repository

As we progress toward a customized WordPress repository, a journey we began last time with some basic Subversion 101, we’ll need to take another intermediate step and study the subversion intermediate course. While SVN 101 gives us a good jumping off point, that really doesn’t get us anywhere near customized WordPress. To do that, we need to take the next step and setup a new repository. You, most likely, can’t make any changes to the WordPress repository itself, so we have to create our own.

Step 1: Creating an SVN Repository

There is a tool that comes with subversion. That tool is svnadmin and it is the tool we use to create a new svn repository. It’s pretty straightforward. First create a directory for your repository:

macbrain:~/svn aaron$ mkdir mywp

Now, we can use the svnadmin command to create an empty repository in the newly created mywp directory:

macbrain:~/svn aaron$ svnadmin create mywp

By convention, every SVN repository should have 3 directories - trunk, branches and tags. This allows us to have development versions of the repository as well as stable versions. For this exercise, we’ll grab the WordPress 2.1 branch and drop it in our own trunk.

Step 2: Trunk, Branches and Tags

First, we need to create the directories. The repository is not a standard file storage kind of thing. You can’t just “create” the folders inside the repository itself. Instead, we’ll have to create an empty directory somewhere and build a layout that we can import into the repository. If you have write access to /tmp, that’s as good a place as any:

macbrain:~/svn aaron$ mkdir /tmp/repo
macbrain:~/svn aaron$ mkdir /tmp/repo/trunk
macbrain:~/svn aaron$ mkdir /tmp/repo/branches
macbrain:~/svn aaron$ mkdir /tmp/repo/tags

Now, we can grab the code from the WordPress repository. The easiest way to do this cleanly is to create yet another empty directory.

macbrain:~/svn aaron$ mkdir /tmp/wp

Then checkout the code:

svn co http://svn.automattic.com/wordpress/branches/2.1 /tmp/wp

Now we have the code, but it is cluttered with hidden folders that allow SVN to know what has changed between the working copy and the repository. In order to place a “clean” copy of the files into our repository layout, we need to do an export:

svn export /tmp/wp /tmp/repo/trunk

Step 3: Importing Into the Repository

The last step in setting up our own WordPress repository is to take our repository layout created in the last step, and import it into the repository itself.

macbrain:~/svn aaron$ svn import /tmp/repo file:///homedir/svn/mywp -m "Initial Import"

There’s a few things to note in the above command. First, you may wonder what the file:/// bit is. SVN understands the second argument of svn import to be a URL. Many SVN repositories, including the WordPress one used above, are accessed remotely over the internet - thus http://, svn:// or svn+ssh:// protocols. However, in this case, we are accessing the repository locally and so the format for designating the local path as a URL is file:/// (three slashes).

Secondly, the file URL takes an absolute path to the repository. In my case, we are using /homedir/svn/mywp, however you should use the path that is relevant to you.

Finally, we need to include a log message for every repository commit. This is added with the -m argument. I find it good practice to designate an import as “Initial Import” and use it consistently. Future check-ins should adequately describe the changeset for other developers who follow later.

Step 4: Updating your Working Copy

Last time, we talked about checking out code. This is the normal routine we would follow when establishing a working copy for the first time. however, as we continue to work on software, and especially if multiple developers are contributing code as well, we’ll want to make sure our working copy is up to date. To do this, we must use the svn up command from the working copy directory:

macbrain:~svn/mywp$ svn up
A wp-config-sample.php
U wp-includes/functions.php
Updated to revision 18.

When we svn up the working copy will be updated and single character codes will be displayed next to files that differ from the previous working copy:

• A - Added
• D - Deleted
• U - Updated
• C - Conflict
• M - Merged

If more than one person is working on code, there is an increased chance of a conflict. A conflict simply means that there is code that is modified in the working copy and in the repository that is different and that manual intervention is required to sort the conflict out. That is for another post at another time, however it is important to note what exactly you might see when doing an svn up.

Next time, we’ll look at svn:externals, a clever way of integrating custom repositories - such as plugins - into your custom WordPress repository.

• 
• Stumble it!

About the Author: Aaron Brazell is the lead editor of Technosailor.com and a social media expert. His passion is to see companies and individuals use the internet and web technologies wisely and effectively to promote their brands and companies. He served as Director of Technology at b5media from 2005-2008 and is currently an independent consultant.