How to deploy a WordPress Plugin with git-svn
UPDATE If you are looking for a recommended way to deploy your WordPress plugins, skip to the UPDATE-section at the end of the article. If you’re interested in a git-svn workflow, read on. Thanks!
— — — — — — — — — — — — — — — — —
Git rocks and GitHub makes it even better. But if you develop a WordPress plugin and aim to share it with the world, you need to use svn. No way!
git-svn to the rescue! (please play your favorite hero-appears-to-save-the-day soundfile)
I assume you have your plugin on GitHub, requested a WordPress.org plugin repository and just received the confirmation mail. What now?
Setup
$ git svn init --trunk=trunk http://plugins.svn.wordpress.org/yourpluginnamehere $ git svn fetch
That might take a while. It’s svn.
$ git branch -a # Lists remotes/trunk $ git rebase --onto remotes/trunk --root master
Woozaa, git rebase magic! Well, it basically applies your linear history (master branch) to the svn repo (remotes/trunk). Now all that’s left is sending the history to the svn repo.
$ git svn dcommit
Oh my god, I hope you don’t have hundreds of commits yet because that will commit each one separately! You probably like to keep your history in svn, so git-svn needs to send each and every commit separately. For me, it took about 30 seconds per commit. So you can estimate how long it might take for you. Gosh. Well, go grab a cup of your favorite hot (or cold, depends on the weather) beverage and enjoy the process. Oh, and WordPress.org will happily send you an email for every commit. Jeez.
Congratulations, you’re done with the unpleasant part – enjoy your WordPress plugin development with git.
Everyday Usage
Develop as you’re used to with git. When you’re ready to release a new plugin version with svn, these are the required steps.
$ git svn dcommit $ git svn tag 1.3 # substitute with your version number
That’s it.
Troubleshooting
You might get errors like W: Refspec glob conflict (ref: refs/remotes/trunk):. Open your .git/config and look for the [svn-remote "svn"] block. Mine looks like this.
[svn-remote "svn"] url = http://plugins.svn.wordpress.org fetch = archivist-custom-archive-templates/trunk:refs/remotes/trunk branches = archivist-custom-archive-templates/branches/*:refs/remotes/* tags = archivist-custom-archive-templates/tags/*:refs/remotes/tags/*
For some reason, I had multiple lines starting with branches and tags. That confused git. Make sure there’s only one line for each option.
Happy developing!
Update
Do not do this. It looks like this workflow is unwelcome as it creates more commits than necessary.
Anyway, I’m already doing it differently now. Develop in git to your liking. When you’re ready to release, bump your version number and simply deploy the current plugin state via svn:
$ svn commit -m "v1.2" $ svn copy http://plugins.svn.wordpress.org/myplugin/trunk http://plugins.svn.wordpress.org/myplugin/tags/1.2
To keep both repos clean, add the line .svn to your .gitignore. Then, type svn propedit svn:ignore . in the plugin root. Add .git and .gitignore on separate lines.
Sources & Further Reading
- stackoverflow: how-to-commit-a-git-repo-to-an-empty-repo-svn-server
- http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
Comments
Was doing exactly this, thanks. Just to be clear:
$ git svn init --trunk=trunk http://plugins.svn.wordpress.org/yourpluginnamehereThis should be run in existing git repository root. It’s not a way to init a new git / svn repository (as I thought first).
Thanks, exactly what i was looking for and worked perfectly
Just tried this, and see ‘git svn’ going through all the revisions on the Svn server. According to http://plugins.svn.wordpress.org/, there are 487558 revisions, so this is going to take ages. Is that expected behaviour?
Hey Martijn,
are you sure you wrote http://plugins.svn.wordpress.org/yourpluginnamehere, not just http://plugins.svn.wordpress.org/ ? Hum, I am not 100% sure about that step.
Anyway, I don’t use this technique any more. Once in a while there was some odd behavior, so I stopped doing it this way.
Now I develop in git only. When a release is due, I do `svn commit -m “release v1.2″` and then tag that release, like this:
`svn copy http://plugins.svn.wordpress.org/myplugin/trunk http://plugins.svn.wordpress.org/myplugin/tags/1.2`
That works and there is no fear that svn clutters your git history with garbage (that’s what happened to me multiple times and I couldn’t figure out why).
Do not do this. If I catch you at it, then I will ban you from WordPress.org.
The SVN only needs your final working version committed to it, not the entire history of the hundreds of changes you made using Git. Flatten your changes to a single commit.
See, the problem with Git is that it encourages people to make tons and tons of commits. Our SVN history really doesn’t need to have every single time you made a change. The plugin repo is a distribution repository, and while small amounts of commits for changes and development are fine, large amounts of them for every single change you made during development is not.
If you use Git, then you should flatten out your history to a single commit, not duplicate your entire history on our SVN.
BTW, there is a better way. Do an interactive rebase and change the “pick”‘s to “squash”‘s instead. Then your dcommit will only commit one change for all of them.
More info here: http://stackoverflow.com/questions/158514/is-it-possible-to-make-git-svn-dcommit-result-in-a-single-svn-commit
Hi Otto,
thanks for the heads up! I updated the article accordingly.
If you’re serious about making money with your website, watch this free video about getting free instant targeted traffic to your site http://instanttrafficrobot2.com
Do you want to get 10000 of free targeted traffic daily from article directories or search engine (google,yahoo bing)? You can easily do that by using our tool at http://articlemarketingrobots.org/. You can try it for free (5 days) and see the result yourself