Photo Credit: Andy Fragen, @andyfragen on x.com.

At WordCamp US in Portland, OR, the Core Committers in attendance had a quick meetup at the end of lunch on Thursday to make sure everyone had met in person and to discuss anything anyone wanted related to the act of committing to Core. Jorbin mentioned it might be helpful if we all shared our own committing workflows on our personal blogs to share knowledge along with some tips & tricks. So, I’ll play along.

Similar to Jorbin, I have a few separate directories of different VS Code workspaces that house the various areas of Core that also vary by purpose. The main two relevant to this are:

• Git Mirror Fork – github.com/WordPress/wordpress-develop
• SVN – develop.svn.wordpress.org

The Git fork is useful to me in many ways. First, at least in my setup, it’s a bit easier to do archaeology on lines/files to backtrace code history. Secondly, I can easily push a change(or many) to a dedicated branch in my fork and have all the GitHub Actions workflows run on that updated code to validate a change. I name my branches something like trac-XXXXX where the XXXXX is the current ticket number in Trac. The only thing I’ve added here is a gh-sync-upstream bash alias to sync my fork to pull in the upstream changes in trunk.

For the SVN workspace, I have trunk and all branches going back to 4.1 checked out. I only use this workspace to commit, revert, merge, tag, etc. When working on a Trac ticket in this space, I rely heavily on grunt patch:xxxxx or grunt patch:https://github.com/WordPress/wordpress-develop/pull/xxxx to pull in patches to commit. I’ll use svn up in the VS Code terminal, and I also have a sr alias that is just svn revert -R ..

I also have a couple of other aliases/function that can come in handy. The first is a interactive script to pipe svn diff to a file, then name it with the Trac ticket number, and even add an “index” if there were multiple patches on that ticket already. Honestly, I very rarely use this anymore, since we have GH PRs.

function svn_make_core_patch {
    read -p "Ticket #: " ticket

    if [ -z "$ticket" ]
    then
        echo "No ticket supplied.  Exiting!"
    else
        read -p "Patch index: " patch_index
        if [ -z "$patch_index" ]
        then
            svn diff > ../../Patches/$ticket.$patch_index.diff
        else
            svn diff > ../../Patches/$ticket.diff
        fi
    fi
}

Next, I have small svn_clean function to clean up both .orig and .rej files that are left when the grunt patch script doesn’t apply a diff cleanly. I run this every once in a while, sorta like taking out the trash.

function svn_clean() {
    svn revert -R .
    find . -name "*.orig" -type f -delete
    find . -name "*.rej" -type f -delete
}

The other thing I rely on in the SVN workspace is npm run test:php and npm run test:e2e to have the unit and end-to-end tests run. I can run the former against a specific ticket number(if it’s been annotated in the tests) or a specific group. This can be faster than push to my Git form and waiting for all the workflows to run again.

One thing that’s a bit different for me is that I am one of the few on Windows. I actually use TortoiseSVN instead of the command line for the actual SVN commit.

For the actual commit, I’ll open Windows Explorer, right-click on the trunk folder(or a relevant branch) and use the TortoiseSVN context menu to “Commit…”. This opens the Tortoise UI which shows the list of modified files in the current directory. I’ll use the “Compare with base” on each file I’m looking to merge to make sure the diff is what I expect, select the files I want to merge(and forgetting to do svn add for new files every friggin time), edit my commit message, then press the button.

Post commit, I’ll watch a few of the GHA workflows run to completion, close any open PRs that were attached to the Trac ticket, and then wait for Sergey to inevitably fix something I screwed up. Finally, I’ll go into the Core admin on Make and manually add props for folks I missed.

Reverts

Reverts are a good thing, most of the time. It means we’re learning something that makes us rethink an approach or give something a bit more time to settle before making it into a WordPress major release. Actually, during this same WordCamp’s Contributor Day, I committed some bad code, then needed to revert. Stupid me decided to bring my MBP that I have only committed on once, so I tried to use Cornerstone(recommended by @desrosj) to handle the revert.

This didn’t go well. I actually reverted someone else’s Contributor Day commit. After that, I’m a bit hesitant to do any SVN stuff on the MBP, so Sergey eventually comes to the rescue to clean up my mess.

So, how do I normally handle reverts? Tortoise SVN makes this pretty easy. There’s a “Revert…” context menu that pops up asking which revision you want to revert. You can even use the UI to browse recent commits, check the box next to a specific one, then proceed. Click “OK” to complete the revert, then just go through the commit process above to merge the revert.

About David

Web Developer