The following is what I came up with. It’s a ruby script that uses the delightful Hpricot gem to parse the xml. It takes one argument, the subversion username that you wish to retrieve the logs for. I hope that it’s useful for someone else! You can curl it from http://pastie.textmate.org/197763.txt if that makes it easier, too.

[ruby]
#!/usr/bin/ruby
require ‘rubygems’
require ‘hpricot’

username = ARGV[0]
if username.nil? || username == “”
puts “Please specify the username to cull log entries for.”
exit
end

puts “Requesting SVN log, this may take a bit.”

doc = IO.popen(“svn log –xml”) do |f|
Hpricot.XML(f)
end

entries = doc.search(“logentry”).find_all do |entry|
(entry/”author”).innerHTML == username
end

entries.each do |entry|
revision = entry.attributes["revision"]
author = (entry/”author”).innerHTML
date = (entry/”date”).innerHTML
msg = (entry/”msg”).innerHTML

puts “r#{revision} – #{author}”
puts “#{date}”
puts “#{msg}”
puts “-”*80
end
[/ruby]

In addition, there’s a new wireless stack, a new Firewire stack (very cool), and a slew of new drivers and other changes. Check out details about this release here, then download the kernel. Enjoy!

Once you start using Rake, you’ll probably find that you duplicate many of your tasks in all of your projects. It’s not too much to copy often-used .rake files, but there is a better way. Sake (short for System-wide Rake) solves this. Once you install a Rake task into Sake’s repository, it becomes available system-wide via the sake command.

Say you have a file named dbversion.rake, which finds the migration version of your database, as follows:
[ruby]
namespace :db do
desc “Returns the current schema version”
task :version => :environment do
puts “Current version: ” +
ActiveRecord::Migrator.current_version.to_s
end
end
[/ruby]

To install this system-wide, first install Sake by running gem install sake. Rubygems will download and install everything for you. Now you can install the Rake task into Sake by typing sake -i dbversion.rake. You can now run the db:version task inside any Rails app by typing sake db:version. Pretty neat, eh?

Sake has a few more tricks up its sleeve. You can view the rake tasks that are currently installed into Sake by running sake -T. It can also install tasks hosted on a remote web server by replacing the filename that appears after sake -i with the url. Check out the original blog post to read more.

Some other sites with info on Rake that I found interesting:

• Some useful Rake tasks from ERR THE BLOG
• A tutorial on Rake from Rails Envy
• A more in-depth view on Rake from Martin Fowler

Give it a try. It costs a couple bucks if you like it, and so far I’ve been very impressed.

When checking out files within the IDE (or even doing updates, for that matter), the sandbox would have its version flags switched, causing my command-line client to no longer work. It got frustrating, as different parts of the sandbox were done in different editors (a Java IDE for one project, a text editor for another, etc), and keeping my sandbox up-to-date was proving tedious.

So, the solution was to update the Subversion client on the command line. Doing so was very easy, though it required building from source (I haven’t been able to find a recent binary installer for the Mac).

Building Subversion from Source
First, download two files: subversion-1.4.3.tar.gz and subversion-deps-1.4.3.tar.gz. Uncompress both of them in the same place (for instance, create a folder called Subversion, place both files in there, and then type “tar xf [file]” for each). This will create a single directory called subversion-1.4.3 with all of the software we’ll need.

Second, in your Terminal, go into this directory and type “./configure”. This will attempt to setup our build. If any problems occur, this will tell you (for instance, I was missing an updated version of apr).

Third, if configure fails, it’s probably due to a missing dependency. For me, I needed to go into the subversion-1.4.3/apr directory, run “./configure ; make” and then, as root, “make install” to get that taken care of. After each dependency you build in this way, re-run the configure script until it completes without errors.

Finally, once the subversion-1.4.3/configure script has completed setting up our build without errors, type “make” to build the subversion software. This is probably the most time consuming and can take a few minutes. When finished, type “sudo make install” to install the Subversion client as root.

And that’s it! To double check that your install worked, type svn –version. If you get a “command not found” error, it’s probably due to your PATH not including /usr/local/bin. To fix this, just edit your ~/.bash_profile, locate the line with $PATH on it, and add “:/usr/local/bin” to the end of the line. Then, type “. ~/.bash_profile” to re-load your PATH, and try it again.

Downloading a Binary
As I mentioned earlier, I had originally opted for the easier path of downloading a pre-built binary of Subversion and installing that. Unfortunately, I haven’t been able to find a recent binary anywhere, and the best I’ve found is version 1.3 (which is where my incompatibilities came from). If this isn’t a problem for you (i.e. you don’t have an IDE that will cause you problems), I suggest going the binary route, as it’s much easier.

Hope you found this useful.

Additional Resources
Prebuilt binaries up to version 1.3
GUI Subversion client (svnX)
Great tips on everything Subversion for the Mac
How to backup a Subversion repository

We’ve been doing some work in PHP lately that makes use of the GD library to do some interesting graphics manipulations. One of the components of the project made use of a transparency color for an image resource, and it seemed like there may have been a bug in the imagefill function: filling with a color of -1 caused the php processor to segfault. What was odd, was a different version (on my Mac), wasn’t crashing at all. This prompted the update to the latest Ubuntu. The latest version, 5.2.1, solved the problem and we were good to go.

Doing an Update (from Edgy to Feisty):
A distribution upgrade with Ubuntu is cake: simply edit your /etc/apt/sources.list file and replace “edgy” with “feisty”. Next, update the sources list (apt-get update will do it), and finally do a dist-upgrade (apt-get dist-upgrade). Check out this article for more details, as well as how to do a dist-upgrade using the GUI.

Check it out. Though we don’t use RHEL on our production machines, a number of large IT departments do. Be sure to post your reactions here.