In my last post I explained how to build a development version of a pecl extension.  Now we will go through the bug lifecycle in the pecl/memcache extension.  Besides writing the actual C code to fix the bug, it is considered a best practice to write a test that verifies the bug has been fixed.  I will use PECL bug #16442 - memcache_set fail with integer value as an example, even though it is already been fixed.

My last post I explained how to efficiently checkout the php svn repository.  Now we need to start building pecl extensions and even php itself.  I prefer to use Cent OS for my linux needs and naturally use rpm's to track all my packages.  This means I have a stable version of php installed with all the various extensions that I could want.  Rather than messing with this stable version, I am going to build a custom debug build of php in /usr/local.  I say "debug", because this build of php will use the --enable-debug option to allow easy debugging using gdb.  Since I am doing pecl extension development, I don't want to build the trunk version of php.  I want to build my pecl extensions against the most recent stable version of php to isolate environmental issues as much as possible.

The svn repository for PHP is rather large.  Trying to checkout the entire repo is both time consuming and wastes a lot of space.  Most people, including myself, are only concerned with a subset of the repository.  One of the advantages svn has over git is the ability to do partial checkouts of the repository.  I am going to borrow from an old email Rasmus sent that details how to do a partial checkout of the PHP source code.

Brandon Savage wrote a controversial blog post about why subversion is still more relevant than git.  His main point was that enterprise requires canonical version numbering to track progress in the application and that git cannot do this.   There was a lot of debate about this on Brandson's, but a recent comment by Morgan proved Brandon wrong.