At WordCamp US today, everyone with commit access to the project was encouraged to document the process they use to commit to changes to the WordPress svn repo.

I’ve experimented with several different setups over the years. Currently, I have two separate directories on my computer that I use while working on WordPress: A git clone of the WordPress/wordpress-develop repo, which I use for development and testing, and a separate svn checkout that I use exclusively for the act of committing to WordPress. I find this separation helpful for me, in that I avoid having accidental changes in my svn checkout that might accidentally end up in a commit.

During development, I work entirely in git, with the WordPress/wordpress-develop repo set as my origin remote. I also have my personal fork set as an alternate remote so I can push branches to that remote when I want to create a pull requests. From the git checkout, I can run tests and linting tools locally for quick feedback, but rely on the CI tools set up on the WordPress repo that run against PRs to ensure the code meets the code standards and quality needed before it is committed.

Once I’m ready to commit, I open my terminal to the svn checkout, and run svn up to make sure my local copy is up to date. I then use the github cli (gh) to apply PRs from the WordPress/wordpress-develop repo as patches to my svn checkout like this (props to Peter Wilson for the approach):

gh pr diff ${PR-number} --repo=WordPress/wordpress-develop | patch -p1

For convenience, I’ve added the following function to my shell so I can simply type gh-patch followed by the PR number:

# Apply a GH PR to SVN.
# Example: `gh-patch 7253` applies the PR from https://github.com/WordPress/wordpress-develop/pull/7253.
gh-patch() {
    gh pr diff $1 --repo=WordPress/wordpress-develop | patch -p1
}

Once the patch is applied, I can inspect that the changes were applied correctly by scanning the output of svn diff, write my commit message (after once again re-reading this handbook page), and commit the patch with svn ci.

When backporting, the process is similar, but first involves ensuring my local svn checkout is on the correct branch and then following these steps, and then (as is tradition) drinking 11 beers.