Informal VIP client survey: how do you commit to SVN?

I am currently a single point of failure for getting code from our Github repo to WordPress.com VIP SVN. As such, we (Fusion) are exploring a project to auto-deploy our Github repository to VIP SVN through post-CI middleware. But, before we dive into development, we want to make sure we’ve exhausted all lower-effort options.

How does your code get from Github to VIP SVN? Would you potentially want ot use our project? Please let me know with a comment — thanks!

9 Comments

Norcross June 30, 2015 Reply

Since VIP (and plugins in the .org repo) are the only things we use SVN for, we use Git internally for storing the code and commit via Cornerstone when it’s time. We have also been exploring setting up an automated way of doing so, hence I’ll be watching this thread closely as well.

Elliott Stocks June 30, 2015 Reply

I’ve used Git inside of SVN and Git SVN before, personally I found Git SVN is a lot easier. However, they’re still not ideal.

I haven’t seen any alternative methods for this. I’d love to see an auto-deploy tool!

Josh Kadis June 30, 2015 Reply

My commits are 100% handcrafted. Pull from Github, commit a few files at a time to VIP (using Versions as a SVN client). I think it’s worth it to take a couple minutes to send a batch of more granular commits that are easier for the reviewer to approve.

Automation sounds good in theory, but our workflows are designed for writing code, not reviewing it.

If, say, every merged pull request on Github generated a single SVN commit, a lot of those commits would be a mishmash of features that would be much harder to review than if the same changeset was broken into smaller chunks.

Weston Ruter June 30, 2015 Reply

I’ve written a script that commits to SVN for a checkout inside of a Git repo. The script creates a vip-committed tag each time it does a commit, and then the next time I do a push to VIP, the commit message is crafted that includes the HEAD commit hash, followed by a git shortlog -sne for a list of the commit authors, and then oneline commit log (without merge commits). It’s basically a git squash merge.

This has been working well, although it does not take into account any upstream VIP hotfix commits, and it does not play nice with Optimizerbot, so I svn revert any image changes at the time of committing.

An SVN commit for each merged pull request is also what I’ve been considering.

Daniel Bachhuber June 30, 2015 Reply

I’ve written a script that commits to SVN for a checkout inside of a Git repo.

What language is the script in?

Patrick Daly July 1, 2015 Reply

Like others, pull down Git, commit in chunks via Cornerstone. It’s entirely risky because I’m 1) being concise with my commits as to make them logical and easy to review, but 2) if the reviewer is trigger-happy they may deploy half of the commits I needed and take a while to get to the second half.

It was talked about over a year ago that they would introduce a Deploy button in the dashboard: they’d review all SVN commits and flag the commits as reviewed somehow and then let the client deploy in their own time. I haven’t heard anymore on that, but if/when this is ever introduced it solves the biggest problem, IMO.

Steph July 15, 2015 Reply

If you leave a note in the commit, like

Commit: 1 / 6
Regular commit message here

We can not deploy stuff when we see that there are more coming 🙂

Gabriel Koen July 1, 2015 Reply

We do all our development in Git. When I’m working on code, I keep a separate SVN repo, rsync the changes over, and then manually review the code before committing. The reason for this is to prevent accidental code from slipping in (that’s mostly paranoia, but we do merge our development branches into the master branch in git, then copy from the master branch to SVN, sometimes we find code that’s slipped into master, doing this process manually helps us catch that rogue code and occasionally we find stuff that should have gone into production and never did).

We’d like to automate the process, but we want to get better about writing unit tests first.

Leave a Reply