Last week I wrote an email to a client who hasn't yet implemented source control, but who is thinking about it. It turned into rather a long email as I attempted to convey WAY too much information in one long email. After some twitter banter, I repackaged my thoughts into a whitepaper on Source Control entitled You're not using source control? Read This! (PDF, no registration needed).

The whitepaper looks at three different tools - Subversion, git and Mercurial (Hg) - and includes a "sales pitch" you can give to the people involved in your project about how it can help them. There's also a few helpful links included at the end for more information about each piece of software.

I work a lot with Symfony2's deps file for installing 3rd party bundles into my project (yeah I know, I should be using Composer, right?). This works really well when working with pure Git. However, when you're not using Git on it's own but instead use git-svn, you may run into some issues when issuing git svn dcommit,

One issue relates to a "Failed to read object" error that could come up during the push. His solution involves a few steps (manual ones) to prepare those bundle directories and make it easier to push the rest of your changes. He also includes a few links to other resources that he found around the same topic.

Some of the more commonly used version control systems that you have likely heard about are CVS and Subversion. This tutorial will take a "forget everything you know about CVS or Subversion" approach. As someone who has used all three of these systems in the professional realm, I can testify that some knowledge of CVS or Subversion can be useful when approaching Git, but it is not necessary. The best way to learn Git is to start using Git for what Git is.

They break it up into a few different sections - why use git, how to create a new repository, adding/staging files for commit, viewing the project history and viewing diffs for different versions. This is the first part in a series, so keep tuned for future parts touching on branching, merging and working with remote repositories.

Market Leader,Inc. is graciously hosting the venue for Seattle PHP Meetup in Kirkland, WA this month!! In fact, Ariz Jacinto (long-time member & frequent presenter at our Meetups), an employee of Market Leader, Inc., has gone bonkers and lined up a killer night for us all! Note the entrance and then celebrate the FREE PARKING!!

Brian Swan is a Microsoft advocate for PHP on Windows and Jesse Keating is the release engineer for Fedora Core. There's still time to RSVP on Meetup and attend this event - be sure to sign up so they know how many to expect!

With CodeIgniter moving to GitHub we are starting to see a lot of CodeIgniter developers wanting to learn more about Git, specifically how they can use it to improve their workflows, manage their applications and move away from the horrible days of copying and pasting updated libraries off a wiki. UCK. Sparks are helping us on the whole, but there is another method that we can use to manage our packages: Git Submodules.

Submodules allow you to pull in source from a remote repository without having to merge the code into your own. It creates a dependency between the two and makes it easier to check out only what you need. He gives the example of his oauth2 package being needed in multiple other applications, so instead of including and checking in multiple versions, he made a separate repo and defined the source as a submodule. He also includes a bit about fixing issues in your submodules with a few handy commands to get on the right branch, add a remote and push the commit.

Rarely a project lives by itself, especially in the days of frameworks. Furthermore, there are a lot of great open source libraries you might want to use to save time. But all of this raises a new problem - how could we manage all those dependencies. Here are some thoughts on this problem and how you might want to solve it; without shooting yourself in a foot.

He mentions svn:externals and git's submodule as options in version control systems, PEAR for package management, Apache Maven and the deps file in the Symfony framework.

Recently I have become quite interested in quality assurance. Not that many things are going wrong for me, but I'd really like to be more certain about the quality of my work. I've used some tools to help me achieve just that. In less than two hours you can set up your workspace and have the living daylights automated out of you!

He provides a full guide to getting the full stack set up including the command-line calls you'll need to make, creating a new build file for Ant and setting up the PHP tools (like Phpmd, DocBlox and Pdepend). In the end, you should see something similar to this setup in your Jenkins build.