So, in my last blog, I said I was using Jekyll to blog now. I also got a new host in Webfaction. So I figured I’d blog about how squished these two together into some blogging without your hands leaving the keyboard. This post will assume you know the basics about Jekyll and git.
1. Upgrade RubyGems and install Jekyll
To install the latest Jekyll on Webfaction, you’ll need to upgrade the version of RubyGems to at least 1.3.7. There’s instructions here for doing that, but I’m going to include them here for you lazy lazers.
It basically involves setting up some Ruby variables, and downloading, extracting and installing the new RubyGems packages.
This will install the gem command in $HOME/bin, and then install the latest version of Jekyll.
2. Install Pygments (optional)
Pygments is a Liquid Extension for Jekyll that will highlight code blocks. If you don’t need code highlighting, it’s not something you need, but if you do it will give you some of the nice formatting you see on this website.
Installation is as follows:
3. Create static application in Webfaction
In your Webfaction control panel, setup a static web application, as shown below. Remember the name of the application, as that folder is where you’ll output your blog.
4. Set up git on Webfaction and your computer
On your webserver, create two directories. One will contain a bare git repository, and the other will contain the actual source of your blog (some info on a bare repository can be found here. I used ~/gitwebsite/git and ~/gitwebsite/ronalleva.com respectively. The rest of these instructions will assume those directories.
Inside ~/gitwebsite/git run:
Now on your own computer, in your git repo for your Jekyll website, run
This will add the repo on your Webfactional server as a remote. Make sure you change username with your username, and the path /gitwebsite/git to whatever you happen to call it.
and that will now push any of your committed changes to your webserver! Woohoo. Oh, and you’ll only need the master call the first time you do it, otherwise it won’t know what branch you’re trying to push. All subsequent calls won’t need the master.
5. Create a post-receive hook
Well, this is great. You’re pushing all your code to your webserver. But it’s sitting there, inert and useless like a sleeping kitten. You’re going to need to run the Jekyll command on your source to get it to show up right. There’s probably one million ways to do this (including doing it manually, using the at daemon, or setting up some type of Rube Goldberg device), but I like doing it with a post-receive hook.
Create a file called ~/gitwebsite/git/hooks/post-receive and place something like the following in there:
The first part basically sets up the necessary variables for working. The GIT_WORK_TREE variable is basically where your Jekyll files will end up. git checkout -f will checkout your Jekyll files into GIT_WORK_TREE. Then the Jekyll command is run, using the webapp you set up previously as the output directory. I put this in a gist, messing up the color style of my website, just so you could fork it! My kindness knows no bounds.
These instructions should be able to be adapted for any web host that allows for shell access (one of the great things about Webfaction). You can find the source of my blog at Github.
Welcome to my new blog. It’s a little rough around the edges at the moment, but hopefully not too bad. I was getting tired of my wordpress blog, so I decided to give Jekyll a try. It’s really fun to work with, and lets you get really fine grained with your control.
Unfortunately I don’t have everything over here yet, but that should hopefully come within the next few days. I’ll also post about the migration from Wordpress to Jekyll.
Wow, I’ve gotten a lot of requests for the jmeter-maven-plugin, for
enhancements and whatnot. I originally had the code on
code.google.com, but from there I have to add contributors, blah
blah blah. So I moved all the code over to github, so if anybody
wants to update it, now they can do so directly, through github.
The page for the jmeter plugin is still
Our group is starting to use
Review Board more and more to
conduct our code reviews.But using it with git-svn, or with
anything you’ve already checked into svn can be a real hassle. You
don’t want to have uncommitted code hanging around in your computer
for extended periods of time for a number of reasons, so this
rendered it difficult to use for code projects that take more than
Since I like to eat, and hence get paid so that I can
afford food, I have to work on things that take longer than a
week. But luckily, git can help get a diff for review board based
only on a string in the commit comments.
This came about when one
of my co-workers posted a bash
scripts someone had written that would
take a git diff and make it into a svn-like diff.
And that worked great. My first attempt was to modify it to do
multiple files at once, but it ended up making a diff for each
revision for each file (if you need that functionality, you can get
So I pulled out python and worked on a new script, which is at the bottom of this post, or
you can get it here.
Once you download the file, you run it like this from your git repository:
The script will take the argument as a string to search for in the
commit comments. This is thanks to the git log --grep=foo command
available in git. It outputs directly to the terminal, which you
can see I’m redirecting into diff.output. Once you have the file,
you can upload to Review Board as you normally would. I did it by
using a search string because we use JIRA to track our work in
svn. We have pre-commit hooks to ensure that we put a JIRA number
on each commit. This helps out git as it has something to search
through to get the change list.
First: It will get all the changes between the first and last revision that
had the search string.
I change File.java under JIRA-123 (now at r1).
Another change to File.java under JIRA-321 (now at r2).
I change the file again under JIRA-123 (now r3).
This script will take all changes between 1 and 3, even if I don’t
want the JIRA-321 changes to show up.
Second: it doesn’t have
any context around removed/moved files. It still should pick up a
renamed file as just a completely new file, but it doesn’t have any
context of renaming. But I believe that’s the case with svn
Third: I am by no means a good python programmer, and
might not know all the conventions that people normally follow. The
code below may cause eye hemorrhaging, face hemorrhaging…pretty
much any of your organs could be hemorrhaged by looking at the
code. CONSIDER THIS YOUR ONLY WARNING. But I did some testing with
newly created files, and removed files, and binary files, but I’m
sure I missed some crazy edge cases. Let me know if you hit any
snags. The script follows:
If you go to the bottom of the page for
under the “Basic Examples” section, you’ll see in there a procedure
to clone a git-svn repo that someone has painstakingly already
cloned from svn. That’s great, because it will save you hours and
hours of mind numbing time that would normally take someone to
clone an svn repo.
That person may be tremendously happy…that is,
until, you try to git svn fetch to get new revisions and branched
and what have you, and you get an error message like this:
> Last fetched revision of (some branch or tag) was r3421, but we are
> about to fetch: r3421!
In an attempt to fix it, you may find
this blog post,
saying to remove the .ref files from your svn directory, which also
The fix: modify the .git/svn/.metadata file so
that the branches-maxRev and tags-maxRev equals the latest commit
revision in svn. So it should look like this after you are done:
Where 17224 was our latest revision.
I got the idea from git-svn’s
webpage, where it states:
> If the subset of branches or tags is changed after fetching, then
> .git/svn/.metadata must be manually edited to remove (or reset)
> branches-maxRev and/or tags-maxRev as appropriate.
I must caveat this with the fact that I have no idea why this
works. Git svn is still black magic to me, and making this work is
akin to me throwing muskrat bones onto a flaming pyre, and drawing
conclusions from the charred remains. Maybe someone with more git
knowledge could drop it off here?