PEAR is about providing the PHP community with reusable, effective components - this has been our mission since day 1. If there is anything we can do to make that goal happen, to assist you as an individual or company, I would strongly encourage you to let us know - we're here to help.

They mention the work of two individuals that have done good work on a specific package, meldra and Gemorroj - perfect examples of how the move to Github has made it simpler to implement changes that have been "waiting in the wings" on the XML_Feed_Parser and Image_Barcode2 packages.

If you've had changes you've wanted to make to a PEAR package in the past but haven't ever gotten them submitted, there's not a better time than now.

While the existing PEAR packages will continue to use the pear.php.net distribution and bug tracking capabilities; it's never been easier to contribute to a PEAR package - simply fork; add your changes and send us a pull request. If your preferred packages aren't yet on github, please feel free to drop us a line on the pear-dev mailing list.

Here's more about the process to get the repository set up and how to migrate your package's current code from SVN over to github. The transition's pretty painless and can make the social development and improvement of your package a lot simpler.

symfony1 is well and alive and many developers are now using it for projects hosted on Git. But as the official symfony 1 repository is hosted on Subversion, it's not always easy to get things versioned easily. As of today, this becomes much more easier. If you are using Git and symfony1, you can now use the official symfony1 Git clone.

There are branches for each of the major 1.x releases as well as tags for some of the minor releases. You can, of course, still access the latest packages directly via the symfony website.

Just over two years since its move from the antiquated CVS to Subversion (SVN), PHP is once again on the move: this time, to Git. Well, eventually. The migration from CVS to SVN was a huge one and took many months. The need for the PHP project to support its user base, hook scripts (commit mailing list, etc.) means that any change of revision control software means quite a large commitment. This is why even though the voting is over, and the dust has settled, we won't be seeing PHP on Git until the end of this year.

Davey shares his vote - pro-git - and explains what his choice (and many others') means for the language, including a modified patch acceptance policy and a convenience for developers to be able to work anywhere.

All in all, I feel migrating from Subversion to Git can only be a good thing for the PHP project and the community as a whole. [...] it is pretty clear that the PHP development community is in favor of the decision.

In his mailing list post, David Soria Parra explains:

After 2 weeks of voting and discussion, I closed the votes today. The results are fairly straightforward. Most of the users want to move to a decentralized version control system. [...] I don't want to make a difference of who voted for what. I think the results are overwhelming in favor of Git.

He'll be working on the spec to make the move for the PHP source over to git and is planning a cut over some time in December. Stay tuned to the php.internals mailing list for more details about the move as they come up.

I've just opened my Xdebug repository on github. Importing my old SVN repository was a bit of a task. With the help of Ole Marius Smestad I managed to cook up a bash script to import and fix-up the repository. In the meanwhile I've learned more about git than I ever wanted to know, but still not enough.

Besides the source for Xdebug itself, you'll also notice repositories for the Xdebug website, the GtkDBGp client and the DBGp protocol definition.

If you're working on a PHP project, like with any other project, probably comes a time when you need to "build a new release," e.g. update the production web site with the latest version of the code. And doing the whole thing manually isn't the most efficient way to get things done, especially if you're lazy, or have to do that every once in a while, over a long period of time. [...] Obviously if updating the site itself could be done without FTP but through a simple svn switch, things would be easier. Still, Phing would allow to make things easier just as nicely. It could for example still be used to create the new tag, trigger the switch, etc

He introduces the process by showing a basic Phing build file that uses the PEAR VersionControl_SVN component to get the latest from the repository and push it to another directory. There was one thing that he wanted to do that the default SVN task couldn't - export the difference between two tags. To make this happen, he had to extend Phing and make a new task - SvnExportDiff. He includes the code for this new task and an updated build file to show it all in use - complete with the FtpDeploy to push the code live.]]> Mon, 20 Jun 2011 11:57:15 -0500 http://www.phpdeveloper.org/news/16330 http://www.phpdeveloper.org/news/16330 In a new post to his blog Chris Jones talks about the "gathering momentum" that's forming around the push to the next PHP release, PHP 5.4, including discussions on mailing lists and IRC.

Discussion on the PHP mail lists and IRC channels in the past few days has been looking positive about an alpha release of PHP 5.4 soon. This will be taken from the "trunk" branch of PHP. The exact feature list is under discussion but the mood seems to be "ship what we currently have" though a couple of features are slated to be deferred until later.

He specifically mentions this mailing list post and the emphasis he puts on testing the code. If you'd like to get involved, you can subscribe to the mailing lists here.

The wiki.php.net box was compromised and the attackers were able to collect wiki account credentials. No other machines in the php.net infrastructure appear to have been affected. Our biggest concern is, of course, the integrity of our source code. We did an extensive code audit and looked at every commit since 5.3.5 to make sure that no stolen accounts were used to inject anything malicious. Nothing was found. The compromised machine has been wiped and we are forcing a password change for all svn accounts.

The issue was caused by a combination of a problem with the wiki software and a Linux root exploit. The Register has additional comments about the issue and outage.

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.