evan.musing << current

When rubinius switched to git recently, we wanted the ability to keep a read-only svn repo running that had the same changes in it. This would let casual people who don’t wish to use git to at least check out the latest code easily. So with some jiggering, I came up with the follow recipe.

1) Setup tailor

Tailor is a python program with is used to translate changes in one version control system into another. It does this by using the native tools for the systems and working copy of code. When there is a change, it simple updates the working copy from the source, then checks them into the target. It’s basically a brute force way, but works quite well.

I use the following tailor config file for rubinius:

[DEFAULT]
verbose = True

[rbx]
target = svn:target
start-revision = c6f4d90df72b103884fa5470a433f5513d2c524d
root-directory = /home/evan/work/tailor/output
state-file = tailor.state
source = git:source
subdir = .

[git:source]
repository = /var/cache/git/code

[svn:target]
module = /rubinius/trunk
repository = file:///home/evan/work/rbx-git-tailor

• start-revision was about 10 commits back from HEAD at the time I did the import. I did this so I didn’t have to wait for tailor to replay all of the commits in git, but still included the last 10. Moving forward, it does all commits.
• root-directory is the working copy directory tailor uses to pull in and commit changes. Make sure it’s an empty directory.
• /var/cache/git/code is a bare git repo, so be sure that repository points to a bare git. In fact, most people will tell you to only use a bare git repo (not one that also contains a working copy) on servers which you push to. push does not update the working copy and it can get quite confusing otherwise.
• The svn target repository should a path that doesn’t exist. Tailor will create the repo the first time it runs. Do NOT point it at an existing one!

2) Git hook

Next, I used the post-update hook in git to automatically run tailor. Heres my post-update hook currently:

echo ""
echo "Updating http://git.rubini.us/svn for the less git inclined"

lockfile -1 ~/tailor.lock

/usr/bin/tailor -c /home/evan/work/tailor/config > ~/tailor.log

sudo -u evan /bin/kill -USR2 `cat /home/evan/work/matzbot/matzbot.pid` > /dev/null 2>&1 || true

rm -f ~/tailor.lock

exec git-update-server-info

The output of the post-update hook goes to the client doing the push, so the echo’s are for the git developers benefit (they’ll probably wonder why their commit pauses at the end if git is sooooo fast otherwise).

I use the lockfile program so that 2 commits don’t try and run tailor at the same time. I don’t know what would happen and personally don’t want to know. Better safe than sorry.

The kill -USR2 tells an irc bot we run in #rubinius that there are new commits to show people. Thats available in git.

Caveats

I have all my git developers pushing via ssh, all as the git user, ie git clone git@git.rubini.us/code. This means the post-update hook is run as the git user. So while the tailor working copy is in my home directory, I’ve chgrp it to git and run chmod g+r -R so the git user can properly use it.

I have the ouput from running tailor redirected into a file, so I can monitor it. So far, the only problem I’ve had with this is that my git user didn’t have a name in /etc/passwd, so git complained about not being able to properly form the author field.

This is read only. Do NOT let people check directly into the svn repo tailor is updating.

A long overdue update about my big project rubinius.

Scheduling

The team is still moving along nicely, still aiming for a 1.0 release by RubyConf 2007. We’ve still got a ways to go, but I’m confident. A part of the team is getting together for a sprint in mid September. Other projects have used sprints to really pull away, productivity wise, and I’m hoping we can do the same.

Git

In the last few days, I decided to migrate the project off Subversion to Git, the DSCM. While I’m certain some will see this as a complete waste of time, I feel that it’s important for the project in the long term, and the developers in the short term.

Long Term

As many people are aware, the mainline ruby interpreter (MRI) suffers a lack of transparency. The perception (I can only speak for rubyists in the US, and perhaps a few in Europe) is that ruby-core team works at their own pace and doesn’t accept much input into the process, nor does it report on the process much.
Now, whether or not you agree with that assessment is not what I’m concerned about. It’s the long term perception and possibility that this same thing could happen to rubinius. So rather than wait and see, I’ve decided that the best way to avert this is to make it as easy as possible to contribute and progress rubinius. Again, some will argue that git was not required to reach this goal, and that is a valid argument. Part of it was just a irrational decision, I’ve been interested in git for a while and wanted to play with it more.

Short Term

Local branches, sane merging, a toolkit interface, oh my! I’ve already fell in love with the parts of git that svn lacks, which in my book, was a reason to switch anway. The tools are richer and more powerful. The code is cleaner. Nuff said.

Application Push

We’re currently in a phase of development I’ve been calling Application Push, which is just a fancy term for try to run shit. The existing body of ruby code is quite dense and provides an excellent proving ground to flesh out rubinius. The project has finally progressed enough that this level of proving can be done. Charles has talked about how this style of dev is what really pushed JRuby to 1.0, so we’re hoping to follow in those same footsteps.

Currently playing in iTunes: The Outernationalist by Thievery Corporation