While working with git-svn over the last week I ran into some minor things that weren't really problems, but still kept my mulling them over every time they happened.

After finishing work on a remote branch I did the usual chain of commands:

$ git checkout master
$ git svn rebase
$ git merge my_branch
$ git svn dcommit

Now, while this works beautifully I had two different experiences how git svn dcommit would put the changes from the branch into the Subversion repository. On one occasion it would just beautifully commit every single commit I did on my local branch. On the other it committed all the changes at once, in one single Subversion commit, using the message "Merged from 'my_branch'".

While it's all no big deal I couldn't put my finger on why it works that way. Either the man page isn't fully clear on the matter, or I just didn't fully understand it. I dug a little deeper through the internets and found out that it will only commit your merged changes as a whole when you did git svn rebase and there were actually changes pouring in from the Subversion repository.

If noone else submitted while you were working everything's fine. Knowing that difference can work out as an advantage, especially if not all of your local commits were clean.

Other than that you can just do the whole procedure from your branch.

$ git checkout my_branch
$ git svn rebase
$ git svn dcommit
$ git checkout master
$ git svn rebase
$ git branch -d my_branch

By the way, you can change the message "Merged from 'my_branch'" by calling git like so:

$ git svn dcommit -e

After more than two days of removing deprecation warnings, adding plugins, fixing some custom additions, going through the whole application, it's finally done. We're running Rails 2.0. Nothing more gratifying than seeing this, well except for the application running without problems:

Picture 1

There were some minor annoyances, but in all it was straight-forward work. One thing was that actsasferret 0.4.0 does not work with Rails 2.0.2, but the upgrade to 0.4.3 doesn't go without any pain either. In 0.4.1 index versioning was introduced which will happily start indexing your data when you first access the index.

Be sure to have the exception notifier plugin ready, that will help you find some of the bugs you might have overlooked.

Rails 2.1, we're ready for you!

It's a classic. You want to return random rows from a table, say a collection of random users in your social network. Easy, MySQL's ORDER BY RAND() to the rescue. After all, everybody's doing it. At least on my last search on that topic, all the PHP kids did it.


There. Does what it's supposed to.

Your social network keeps growing and growing and after about a year and 50000 new users you realize a slow-down on the page where you show random users. You're thinking of caching it, but what's the point? It wouldn't be random.

You break it down with EXPLAIN and realize with horror that your fancy query doesn't use the nice index you placed on the table ages ago. And why would it? It's calling RAND() for every row in your table, there's just no way around it. So what to do?

One alternative is to fetch random IDs first and then join the IDs found with the USERS table to fetch the real data. How do we do that? Why, using ORDER BY RAND(), of course. Wait, didn't I just say you're not supposed to use it? Well, I did say that, but the difference is that we'll run the ORDER BY RAND() on the best-indexed column there is, the primary key. Let's break it down and get our hands dirty:


And with a little bit of thinking we got ourselves a nice and fast way to fetch random data. Most likely there are other ways out there (sometimes I do miss Oracle's ROWID), but this one worked fairly well for me. It probably won't scale forever though, so be prepared to get back to it every once in a while.