Since its inception, Zend Framework 1 has used Subversion for versioning. However, as we approach its end-of-life (which will occur 12-18 months from the time this post is written), and as our experience with ZF2 processes becomes more familiar, we -- the Zend team and the Community Review team -- feel that we can better support ZF1 via GitHub. As such, we will be migrating the ZF1 Subversion repository to GitHub this week. Please read on for details!

The post details the steps that'll be taken during the process including the changing of the location of the "master" branch (and how to change svn to point to it) and the updates to the integration of the Dojo libraries. They also talk some about the "extras" repository and how things will work with the Issue Tracker and pull requests in the future.

The repository and issues migration is the first step in a series of planned migrations. We also plan to eventually migrate our wiki to GitHub; this will allow us to offload functionality from the main ZF website, and also consolidate all development-related functionality (other than the mailing list) in a central location.

Creating a staging environment is specific to your production environment. There is no magic solution that works in every situation. But most cases follow a similar pattern, and I'll cover all the key points as we go along. It's fair to assume that most people deploy their apps with some kind of versioning tool (like GIT). [...] Besides GIT, you have to think about the languages, software, and "special" features your production servers offer.

All of the commands and configuration files you'll need to make the automatic setup work are included in the article. It's based on a Debian (Squeeze) base image and uses packages to install the needed software. They also install other PHP extensions like mycrypt, GD, curl, APC and database support (MySQL, SQLite and Postgres). They help you get Apache set up to serve the application and work with git and its hooks to push the code and run Composer.

Dear PHP Community, we need to have a talk about the insufferable state of your software stacks. It was recently brought to my attention that there is software out there, software we use every day!, that is NOT written in PHP. This is completely unacceptable! We are PHPeople! We're not "Web" Developers, we are the web. And we sure as hell are not some fancy "Software Developer", you can ask anyone on the internet! Seriously: If it's not PHP how will we ever be able to extend and adapt it to our needs! We are slaves of our tools!

He mentions several tools that, yes, while not written in PHP are very useful to just about any developer out there (including git, Puppet and Apache). But, more seriously:

PHP is a language that enables absolute beginners to start creating on the web using FTP and notepad! It let's us realize and validate our ideas blazingly fast and allows us to adapt our successful ideas to beautifully scale with our requirements providing and relying on solid, battle-proof tools.

Often I find absolutely competent programmers, who aren't involved in open source, either because they don't know how to approach a project, or because they just aren't sure how the process even works. In this article we'll look at one example, the conference feedback site joind.in, and how you can use GitHub to start contributing code to this project. Since so many projects are hosted on github, this will help you get started with other projects, too.

She covers all you'll need to know to get in and get going with Github - forking a current repo (she uses Joind.in as an example), cloning your fork, making updates and submitting them as a pull request back to the main project. There's also some things about general git topics like branching, merging from the upstream source and using "git log" to view the changes.

aking your repositories available in a local intranet is pretty easy, but having a nice interface to interact with those repositories, making collaboration between teams easier, is not that simple. [...] There are other solutions available, but some are too hard to install or, again, hard on the eyes. I recently discovered GitList, a free and open source Git repository viewer. It's interface resembles GitHub a lot but aims to keep everything simple and clear.

He includes the basic installation steps you'll need to get it up and running - setting up the environment, downloading and configuring Gitlist to look at your repositories and pointing out that, since the LESS source is included in the download, you can customize it how you see fit.

Up until a few days ago I used to use a small bash deployment script to deploy a few simple sites to my live box. The process was a git archive and extract, then an rsync to the live site. Only inspecting it recently I realised that rsync no longer sent just the changes but all of the files, I'd never noticed before as the sites were so small the deploy was over very quickly. The rsync used to work fine before as I would deploy my current working code where the timestamps on files would match the server. Since I started using git at home for dev, the git archive method timestamps the files with the latest commit's timestamp. This messes up rsync.

His process involves a checked in version of Silex, a development branch, a push of the code to the live machine and an install script to set up Silex. He includes the "technical breakdown" and the information needed to replicate it - the .gitignore, setting up password-less SSHing, setting up the server and creating the git post-receive hook (a bash script).

Each of them has its own advantages and disadvantages so the project's requirements, development environment and team members receptivity should be taken into consideration. Relying on my own experience in project management and using version control systems to manage the development process I've formed the conclusions listed below that may be helpful while considering usage of one of described SCM's in your own projects.

He talks about how the size of the project can effect the decision and a bit more detail about what each of the version control systems are good at. The PHP project itself has recently made the shift to git away from Subversion (you can find more information on the PHP.net site).

The PHP development migrated to a Git repository. With the integration with GitHub it became easier for non-core developers to submit pull requests with bug fixes and new feature improvements to PHP. Will this new possibility make it PHP core developers accept more contributions from non-core developers?

The episode also looks forward to the next release in the PHP 5.4.x series (5.4.1) and some of the stir that a recent post (to PHPClasses) about OOP caused in the community.

You can listen to this latest episode either via the in-page player, by downloading the mp3 or by subscribing to their podcast feed.

Why write something of my own? Well, of course, there's the fact that I'm a developer, and have control issues. Then there's also the fact that a blog is both a simple enough domain to allow easily experimenting with new technology and paradigms, while simultaneously providing a complex enough domain to expose non-trivial issues.

He realized that he wanted a platform that was not only something he wanted to maintain but that also allowed him to write how he wanted to write - no more in-browser editing, just working with text files and generated page output. He shares some of the thoughts behind the different parts of the blog software - the domain model, his PhlyBlog module and the updated code he used to override some of the functionality in this default module. He also describes his new blogging process which includes git branching, creating a PHP "post" file, regernerate the blog via a command-line tool and merge and deploy.

He guides you through the entire process:

• Setting up a micro instance on EC2
• Signing up for unfuddle (for git)
• Installing Puppet (standalone)
• Setting up your git repository to point to unfuddle
• The needed Puppet configuration files to get the WordPress instance deployed

Complete code (and commands) are provided in the post.