On his blog Sebastian Bergmann has a recent post about how he's visualizing PHPUnit's development and pushing that information into a video based on the history of the project.

According to svn.php.net, I committed the first PHPUnit code to cvs.php.net on November 27th 2001 and the first release, PHPUnit 0.1, was made on December 1st 2001. [...] On December 26th 2009, I moved the development of PHPUnit from svn.phpunit.de to GitHub. I imported the history from Subversion into Git. As you can see in the video, moving to GitHub lead to an increased number of contributions to PHPUnit.

You can watch the video either embedded in his post or directly from Vimeo. It's interesting to watch the progress of the application and see the contributions make to each of the parts. The whole video, spanning the entire commit history of the tool, lasts about 25 minutes.

In a new post from Lukas Smith's blog he talks about the project's move to Subversion and away from CVS and how that's affected the language's development in a very positive way.

I remember that back when I was co-RM for PHP 5.3 one of the very painful parts was the crying and moaning about the commit freezes we put into place while packaging up a new release. The reason being we were on CVS, if people kept committing while a release was being tested it would effectively prevent any sort of QA.

Because of problems like this (and many others), the group decided to drop CVS for their development and head to the brighter land of Subversion. So, instead of having days when no commits are allowed, correct branching and testing make it much easier to develop one of the web's most popular languages.

The change came with some new branching techniques and some of the developers in the group aren't as happy about how they're handled. Some new tools have been developed to help minimize the risks that these methods could cause, though, including this site.

Matthew Turland has posted a guide to compiling PHP with the Tidy extension (a tool to clean and repair HTML documents through direct manipulation).

I dug around a bit, but most resources I came across on Google were about using the tidy extension for PHP rather than doing a custom build of PHP that included the tidy extension. Once I figured the details out, I thought I'd share. They admittedly seemed somewhat obvious after the fact, though also were not communicated as explicitly as I would have liked anywhere that I could see.

TO use his method you'll need to have CVS working (either on a server or, like he did, a local machine) and be able to grab the latest PHP 5.3.x and tidy extension versions. When you do the compile for PHP, all you need to do is point it at the CVS checkout of tidy and you should be all set.

The PHP project has been making a major change lately - an upgrade of their version control system of choice from CVS to Subversion. They started the move the other day and now, according to this new post on the PHP.net website, the process has been completed.

The migration from CVS to Subversion is complete. The web interface is at svn.php.net. You can read about it at php.net/svn.php, wiki.php.net/vcs/svnfaq. The URL to feed to your svn client is http://svn.php.net/repository. There is also a github mirror. Please use that instead of trying to do a full git clone from the svn repository. See the instructions at wiki.php.net/vcs/svnfaq#git.

The instructions contain complete information on how to get and compile this "bleeding edge" (and what libraries you might need to install to get it up and working).

Kevin van Zonneveld has posted seven steps that you can follow to help the documentation for your PEAR class come out better and be more useful in the end.

If you've written a PEAR package, it's probably a good idea to submit some end user documentation. Here's how to do it.

He explains what it is (XML in CVS, easily convertible with phpd) and how the process flows - save the current docs, add your own, build locally and submit to CVS. Here's his tips to help things go smoothly/turn out better:

• Gather the prerequisites
• Save current documentation
• Try building the docs
• Write your own XML docs
• ReBuild peardoc
• Commit your XML
• (There is no seventh step - you're done!)

In this new post to her blog Elizabeth Smith takes a look at something easy you can do to help out the PHP project without ever writing a line of C code - helping the Documentation project. How, you ask? Well, if you're working with Windows, this is your lucky day. Elizabeth uses the rest of the post to show you how to install PHP, grab the phpdoc XML files from CVS and get PhD up and running.

So, you've decided you want to help out - where do you start? Before you can edit a file or document an extension you need to be able to build the manual to check your changes. So you need a working install of PhD. In order to accomplish this goal you'll need three things installed and configured, which is what this article is intended to help with.

You might need to grab a few other things (like the Microsoft 2008 C++ runtime or a QA build of PHP 5.3) to get things running, but her guide - complete with screenshots - walks you through every step of the way. For those that are a bit more experienced with working with Windows & PHP, you might find the five minute install a bit faster.

Chuck Burgess has posted a guide for developers out there wanting to get their PEAR packages working with phpUnderControl for builds.

there were some things that I had to discover via trial-and-error with regard to the build files, though possibly they are covered in other pUC docs that I didn't check. The "Getting Started" build example is based on a project sandbox pulling code from a Subversion repository, whereas all my PEAR code comes from CVS.

He talks about his config.xml file (how it turned out that the basic one was all he really needed) and configuring the build.xml to run the tests from the correct location. He also mentions some future ideas like making the builds run the install/upgrade commands before running the tests.

In a recent post to his blog Daniel Cousineau shows a method for correctly outputting CSV data in push down to the client browser as a method of export.

Nearly every application you could write in for the business sphere in PHP probably requires some sort of data export, most likely in the CSV format. The easiest way to provide a downloadable file is by altering the headers and echo'ing the file content.

His method sets the headers for the CSV file type then pushes the content out (contained in an array) via the fputcsv function. He wraps it all in a function near the end for simple cut and paste.

Jacques Marneweck has a quick reminder for those trying to get the latest PEAR installer - you can always get it from CVS.

Quick note that the PEAR installer is missing (go-pear.org has expired and has been snapped up by some cybersquatters) and http://pear.php.net/go-pear renders a 404. So the current solution is to grab the go-pear install from CVS.

A quick curl call to a url on the cvs.php.net site (in the /pearweb directory) is all it takes to grab the latest. The page it's pulling is the source for the go-pear.php installer that can be run either from a web browser or from the command line (with a PHP binary).

Ken Guest has posted a review of yet another PHP-related book from APress publishing, "PHP Objects, Patterns and Practice (Second Edition)".

While being an easy read, this is a well written, serious book and is aimed squarely at enterprise-level developers and software engineers who make their living through the development and architecture of solutions developed in PHP.

He breaks down the book into the three sections its title mentions - working with objects, design patterns and a healthy dose of PEAR, phpDocumentor, PHPUnit, CVS and phing.