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:

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

directory:

By convention, every SVN repository should have 3 directories –

,

and

. 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

.

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

, that’s as good a place as any:

1
2
3
4
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.

Then checkout the code:

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:

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.

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

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

, 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

command from the working copy directory:

1
2
3
4
macbrain:~svn/mywp$ svn up

A wp-config-sample.php

U wp-includes/functions.php

Updated to revision 18.

When we

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

.

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