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.

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 migration of the PHP source code from Subversion to Git is complete. You can clone or fork the source from our GitHub mirror, and we also now support pull requests made via GitHub. The source is also available via git.php.net, and full instructions on cloning the php-src tree can be found at php.net/git. One immediate benefit is that future PHP release tags will be signed by the PHP development team. We will be releasing GPG keys for verification purposes in the next few days. More information on the migration and the new workflow can be found at the Moving to Git FAQ on the PHP Wiki.

This move does not include the manuals yet, but that's coming soon. Be sure to follow these steps if you'd like to contribute back via the git repository. This is a great move for the project and makes it even easier for developers to contribute their fixes and ideas back to the development group!

Joshua Thijssen has also posted a guide to getting started on his blog.

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 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.

The Phing and Propel Subversion repositories have suffered from long downtime periods quite often recently (last one was today). It is quite annoying as when it happens, you cannot easily update your symfony repositories, let alone the checkout of a symfony branch. To make things worse, the Doctrine repository also had some problems recently. A lot of symfony users are quite upset by the situation, myself being the first one.

The solution - create some mirrors to provide more than one source to fetch the latest checkouts from. Here's the list of the new resources: Phing mirror, Propel mirror, Doctrine mirror.

Now that pear2 is in svn.php.net, it is possible to do commits with multiple packages using a feature of subversion called "sparse checkouts." [...] Here is the version I used to set up pear and pear2 in a way that will allow committing to both pear and pear2 packages in a single commit.

Rasmus Lerdorf has written about the same thing for the main PHP side of things. All the commands you'll need are there to get things set up and working more efficiently.

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).

After Lukas asked me for the current Planet sources, I realized that I didn't really maintain the sources in the mentioned SVN repository anymore (for various reasons). So I decided to finally move them to GitHub. It makes much more sense there, since the most decent thing to do if you want to set up your own planet is to fork it and git (plus GitHub) makes that painlessly easy. Nevertheless I'm of course still interested in patches.

He warns that the code is a bit on the old side and that the framework its based on has officially been deprecated. If you're still interested, though, you can find (and clone) the application from its GitHub page.

After recent complaints in the PHP-GTK mailing list, auroraeosrose mentioned mgdm has set up a SVN repository for the docs, to ease working on them. This new repository is available at http://svn.thefrozenfire.com/phpgtkdoc/

The trunk currently has repositories for the gtkdocs and the phpdoc application you can check out and use to generate and develop on the documentation locally.