andthennothing.net

Today I finally made the first feature addition to this blog since its launch. I’ve been having some instabilities with Eclipse / RDT and my Subversion repository, and updated my Typo installation so I haven’t been able to work for a while. The feature is nothing spectacular but just a tag cloud which I’ve been wanting for a while.

This is the first time I’m updating my Typo installation, and the update contains changes to the database schema as well to make things a little bit more interesting.

$ mysqldump -C -u username -p --opt --lock-tables=false --skip-add-locks --skip-extended-insert database > dump.sql

I fetch the dump to my laptop and bring it into my local MySQL server (using SQLyog, but could just as well have used MySQL directly). Updating to latest version of Typo.

svk sync --all
svk update andthennothing-dev
svk smerge //typo/mirror andthennothing-dev
svk commit andthennothing-dev

When I try to run Typo now it doesn’t work since the database schema has changed. This is where Active Record’s Migrations come in. It should be as easy as rake migrate, but it wasn’t for me. Not this time. First I try it out on my laptop and since the Typo user doesn’t have all permissions needed some of the migration steps don’t succeed (that’s at least what I think went wrong). However, after changing the permissions of the user, changing schema_info.version to 18 (the version it was before I tried to migrate) and re-restoring the dumped database it works as expected.

Since I don’t want the same problem on my production server I create a test database and checkout the new Typo version in a temporary directory on the server. But it failed in another way:

$ rake migrate RAILS_ENV=test
rake aborted!
WARNING:  You have a nil object when you probably didn't expect it!  Odds are you want an instance of Array instead.

Look in the callstack to see where you're working with an object that could be nil.
Investigate your methods and make sure the object is what you expect!
./rakefile:218

The reason was that the schema_info table somehow was empty, don’t know how it happened. But adding a record with version = 18, the migration works.

After some testing locally of the new version I’m ready to push the new version to the production server. Merge dev to trunk locally:

svk update andthennothing-trunk
svk smerge //andthennothing/branches/dev andthennothing-trunk
svk commit andthennothing-trunk

$ killall lighttpd # I think I'll manage some downtime
$ svn update
$ rake migrate RAILS_ENV=production
Trying to add whiteboard to: articles... comments... pages... done.
Renaming Articles table
Copying article data
Adding a type column
Extending Content table
Converting comments
Extending Content table
Converting trackbacks
Extending content table
Converting pages
Updating all articles
$ #restart lighttpd

Everything seems to work just fine! The update took something like one or two minutes I think, which is quite an acceptable downtime on a personal web site. I will look into how to update without any downtime some other time since I think it’s possible with Rails.

It was a quite painless experience once I figured out how to get around the problems, and I’m glad I tried it out locally first. Rails Migrations rocks! The only objection I have is why it didn’t perform the migration in a transation so when it failed the first time it wouldn’t have screwed up my database?

Update: The transaction problem is fixed by scott.

As I was getting ready to get this blog out the door I wanted to change the permalinks for the entries. Normally on a Typo powered blog the entries are places under /articles/YYYY/MM/DD/name/, but I wanted to change from articles to archives. So I started updating config/routes.rb and all the places where links were created (which is quite a few). I actually got a little angry that they didn’t use custom helpers to generate all links, since it would be much easier to make the change in on place (putting them together with the routes would be even better, I thought, to honor DRY).

But somehow I realised that Rails was cleverer than that. Actually, routing works both ways – both for incoming requests and for URL generation. url_for (which is used to create URLs for links etc.) uses the routing to create the correct URLs. So to change from articles to archives all that was needed was to change config/routes.rb and everything worked. I think it’s neat with separation between URL design and controller names!

Rails’ “convention over configuration” hides some of its neatness so you’ll have to do some digging.

On a day-to-day basis I’m using Perforce at work for my SCM needs. I’ve used CVS a few times back in the days but I’ve tried to forget about it :-). But as I’m migrating to my new web host I have to learn how to use Subversion (svn). The main issue I saw was how to manage multiple branches and repositories.

I asked at the Typo mailing list, and a similar thread appeared on the Rails mailing list, and the general recommendation was to use svk (especially this mail won me over). Other reference material I used was this, that, and the other. This is a writeup of how I went about (it might not be that easy to understand and a little more explanations are probably needed for this to be helpful, but just ask me if there is something that you don’t understand):

Installing svk from here.

svk depotmap --init
svk mkdir //typo
svk mirror svn://leetsoft.com/typo/trunk //typo/mirror
svk sync //typo/mirror
svk co //typo/mirror typo-mirror

Seems to work.

I’m a little bit worried at this stage. I’d like to use the Eclipse plugin subclipse when developing. Perhaps I should only use svk when migrating between different trees. Yes, I think I’ll go for that, and to make it smooth I’ll keep all svk checkouts (svk co --list) in one directory called svk. So let’s relocate:

svk co --relocate typo-mirror svk\typo-mirror

I might change my mind further down the line and want to use svk exclusively, but I don’t expect that to be a problem since svk appears to be quite flexible.

Time to move into svn land. I need to create a trunk and a development tree on my Textdrive repository.

svn mkdir http://urltorepository/trunk
svn mkdir http://urltorepository/branches
svn mkdir http://urltorepository/branches/dev

svn co http://urltorepository/trunk site-trunk
svn co http://urltorepository/branches/trunk site-dev

Back in svk land.

svk mirror http://urltorepository //site
svk sync //site
svk co //site/branches/dev site-dev

Time to do a baseless merge from Typo to the dev branch:

svk smerge --baseless //typo/mirror site-dev

Since the dev branch was empty before it’s safe to commit the changes without reviewing: svk commit.

Time to update Typo with the changes I’ve done previously. svn update in my site-dev checkout. Firing up a favourite open source utility of mine: WinMerge. Takes a while to merge all the files, but now I’m done, just have to try out if it works alright. It seems to work fine. svn status. Hmm, most of my customizations of Typo is in the views, and looking at this ticket Typo is apparently supporting themed views, have to try it out… Yes it works, neato! svn add on all the new files and svn commit.

svk sync //site
svk co //site/trunk andthennothing-trunk

svk smerge --baseless //site/branches/dev site-trunk
svk commit

I think that’s it and hope it will be quite easy to manage in the future. There are two main cycles I’ll be performing. One is getting updates from the Typo repository, and then migrate the changes to the dev branch to the trunk. The other one is migrating changes I’m doing to the dev branch to the trunk. Both of those should be quite easy to manage in svk. I think that the dev branch might be unnecessary, but I’m used to working with a lot of different branches (release, import, team, personal etc.) so that’s how I’m feeling comfortable at the moment. But it will probably be quite easy to remove the dev branch if deemed unnecessary.

Both svn and svk are new and welcomed acquaintances. Working in the command prompt with SCM tools were nicer than I thought and remembered. Hopefully I will have the same opinion in a couple of weeks when I have a little more experience with merging and resolving conflicts (I’m somewhat worried that it will be cumbersome). svn’s poor support for branches and merging is my main pet peeve, but svk handled that nicely. I would go for a svk only (on the client side) if there were a Eclipse plug-in.

Nice learning experience!