At the end of this week I’ll be in Copenhagen for the Nordic Perl Workshop. I’ll give two talks about GNOME and Perl: the first one is about binding GObject-based libraries in Perl and using the Perl bindings in order to write GObject-based native Perl modules (and get all the GObject features); the second one is a GTK+ tutorial-slash-faq-slash-best practises for Perl developers. I’ll be around in the city from the 27th till the afternoon of the 29th (I have to get back early, unfortunately).
Get Innocous!
Lately, people have been trying Clutter, and reported bugs and misbehaviours. When asked what revision they were using, it turned out that they did a checkout from Clutter-core trunk. I made this point on the mailing list already, but I’ll just blog it so that it doesn’t get lost (until we have set up some web archives for the list): Clutter trunk is meant to break basically with each commit – so you should checkout trunk only if you want to help developing Clutter. If you want to use Clutter from SVN, check out the clutter-0-2 branch. Each stable release of Clutter (0.2, the next 0.4, etc) is guaranteed to be ABI and API compatible within the same minor release; until we reach 1.0, we’ll also keep providing support for parallel installations, so that you can target a specific minor revision without breaking.
So, if you want to try out Clutter, use the stable branch – and remember to file bugs against that.
Falling Away With You
A couple of weeks ago I decided to give git a try, after this old post written by nud about using git-svn to create a bridge between a project stored under a SVN repository and a git repository.
I’ve choosen Clutter mostly for these reasons:
- I wanted to create a distributed branch of Clutter in order to avoid huge commits after offline periods
- have a semi-private crack-powered tree for experimenting with some ideas without having to taint the SVN repository
- the number of revisions in the main repository is low (< 1000) so I could import the whole history in a reasonable amount of time
I fired in my terminal the git-svn commands and less than ten minutes later I had a fully working git repository for Clutter, complete with history. What I liked from the very beginning were the lightweight branches git employs; you can have multiple branches inside the same work directory and you can switch between them with a single command. Actually, I found that having a single branch for each one of the changes and then merging them back into the main work branch is an incredibly natural way of dealing with the development of a project; it’s like having a locally distributed approach – which git makes it easier to adopt than, say, bazaar; the git-web interface is also really sweet, and much more useful than viewcvs alone (and, in many cases, of the viewcvs+bonsai coupling); finally, the speed factor is huge: each command, except for the cloning of a repository (which is something you end up doing just once anyway) is almost immediate.