End of one era, on to the next

Automattic has claimed ownership of the plugins I worked on during my employment. As such, the VIP team and others will be taking responsibility for their continued development, maintenance, WordPress.org support, etc. Hopefully they remain independent and aren’t rolled into Jetpack. I’ll contribute as relevant to Human Made projects, but will no longer take an active role with the plugins.

These plugins include:

  • Edit Flow
  • Co-Authors Plus
  • Ad Code Manager
  • P2 Resolved Posts
  • Document Feedback
  • Rewrite Rules Inspector
  • Custom JavaScript Editor

Sometimes what appears to be a curse is actually a blessing in disguise. Human Made has pretty neat products in the works that I’m enjoying applying my creative energy towards. Stay tuned for that. And, on the open source side of things, I’ll have more time to contribute to wp-cli.

To everyone who’s used one of the above: it’s been a pleasure working with you. I’m looking forward to the opportunity to do so again in the future.

Git in my Subversion

Two weeks ago, I discovered magic: it’s possible to initialize a Git repo inside of Subversion (SVN).

Since the advent of Github as a leading collaboration platform, I’ve forever been trying to reconcile the Git to SVN workflow. Progress is faster in Git(hub) because it’s a far superior platform for fostering contributions. Seamless pull requests are much nicer than the multi-step process of creating and uploading patches. Distribution still happens in SVN, however, because many legacy deploy systems are coupled to it. Etsy took the leap of switching from SVN to Git, and essentially recommends against it. For the time being, we need to be able to live with both.

Two years ago (almost to the day), I wrote a post called “How to properly use Git with WordPress.org Subversion.” The thing is though — it wasn’t ever properly using Git with SVN. It was grinding the two tools together like a sixteen year-old learning to drive a stick. Furthermore, if I ever nuked my Git repo, I’d have to wait literally for hours to run git svn fetch on the WordPress.org repo. Boone has worked in a similar way for a while; I eventually gave up and started copying my files over manually when I needed to release. Mo does this with an rsync command.

A recent stroke of insight has changed my outlook on life, improved how I sleep, increased my libido, and generally made me a much happier developer. It’s this: Git and SVN can live side-by-side in the same directory. You just need to tell them to ignore each other.

This afternoon, for instance, I decided to spend a little bit of time on Edit Flow. I like to develop Edit Flow locally, keep the WordPress.com VIP shared plugins repo version on the bleeding edge, and occasionally release a version on WordPress.org. Because I haven’t yet applied this “Git in my Subversion” approach to what’s in the latter two repos, let me now walk through what that looks like.

The first thing you should do is edit the “svn:ignore” property on your existing SVN repo. You can do so with:

svn propedit svn:ignore edit-flow

In this situation, I specifically want SVN to ignore two things: .git and .gitignore. Add those, save, and commit. SVN will now respect Git’s living style.

Next, change into your target directory and initialize a new Git repo. Running the following pulls my full remote project into the working directory:

git remote add -f origin https://github.com/danielbachhuber/Edit-Flow.git

But, if I run git status, I’ll see that my local working files aren’t tracked by Git, I can’t checkout master or change branches, and Git is flummoxed. Don’t worry — as long as you’ve kept Git as master, and ported your SVN commits back to Git, you can run:

git checkout -f master

Boom, Git in my Subversion. Running git status I notice there’s a lot of .svn junk I don’t want tracked in my repo, so I create a .gitignore file to handle those (on WordPress.com trunk, I also ignore the wpcom-helper.php file we use for every community plugin to handle local action and filter modifications). The integration is complete.

With Git and SVN side-by-side, I can easily pull features I’ve developed locally into the VIP shared plugins repo, VIPs can create pull requests for community plugins, and I can push hotfixes discovered by WordPress.com usage back to the Git(hub) master project. It works well because Git and SVN are tracking the same files, but I don’t have to get them to live together harmoniously — they just ignore each other. Git-SVN be damned, this is much better.

Status

Flew down to San Francisco this morning in preparation for WordCamp San Francisco. I’m excited and nervous; my Saturday afternoon talk will likely be in front of the largest audience I’ve ever seen. That is, unless everyone ends up in the other track.

Mostly though, I’m looking forward to hanging out with the community. And, if it’s possible, find people using Edit Flow who’d like to get involved with an upcoming release!

How to manage a proper multi-author WordPress blog

How to manage a proper multi-author WordPress blog. Latest version of Edit Flow makes the list of recommended tools. Interestingly, at the top of the list is a team blog, P2 in fact, for authors and editors to discuss ideas, share links, etc. Now, if only that were embedded within the admin too…

Status

Based on a bit of documentation I’m writing now for work, here are two features I want for Edit Flow:

  • Task list (similar to Basecamp) – Identify the points I need to cover when they come to me, and then make sure I cover them.
  • Editorial markup – Highlight a bit of text to record I need to fact check the statement, expand the idea, or eventually clarify further.