Kubuntu 8.04 (Hardy Heron)

I’ve decided to reinstall my Linux system, and in the process upgrade to the next Kubuntu version, 8.04, also known as Hardy Heron. I usually don’t like to reinstall my OS when I upgrade to a new version. One of the reason I decided to move to a Debian distribution was that I didn’t have to reinstall during upgrade. Unfortunately, when I initially installed Kubuntu 6.06 (Dapper), I made the / partition too small. Although it was big enough for normal usage, during upgrades, with multiple versions of the kernel, firmwares and kernel modules, it got too tight. Hopefully, the current size of 1 Gb should be enough.

In general, I hate reinstalling an OS. Mostly because I spend some time customizing it, writing scripts to help me in the day-to-day work. Most of the time, I forget to backup these scripts, so I have to recreate them once I notice they are missing. Mostly finding everything to make the desktop look and feel exactly as I had it before I made the upgrade do take time. Of course, I’m also finding functionality that I’ve never noticed because they have been hidden because of customization, or I just hadn’t looked.

Although I stopped installing beta software (unless force to it), I’ve been pleasantly surprised by the stability of Hardy. Stuff like hibernation and suspension that I previously had problems with, works now. I never got the kernel in Gutsy to boot, so I had to be content with the kernel from Edgy, but 2.6.24 works perfectly now. And Kontact seem more stable than previous versions. The addressbook has gotten a much needed speedboost (when using LDAP), although it still doesn’t expose all the fields. This version seems to be a keeper.

Distributed Version Control Systems

I recently moved all my development over to a distributed version control system (dvcs) called git. I’m not going to write about dvcs and the difference/advantage/disadvantage between it and central version control systems, like Subversion. There several good articles and blogs on that topic around already [1][2][3]. This is more about my journey.

I started my (development) career using SCCS and RCS slowly moving towards CVS. They worked, with some warts. Some of the weaknesses are well-known, but for tracking individual files, they work really well, and I still use it. Once Subversion came on the scene and stabilized (with the introduction of fsfs repository type), I was hooked. One of the thing I really liked was the concept of change set, that is set of changes that logically belongs together. Like say, a header file and the source file. Change the header file and the source file needs to be changed too.

I recently got in trouble with my svn repository when my working set got into an invalid state as far as my repository was concerned. What happened was, when I moved back to Norway, I shipped my computers. I had made a backup, but had continued developing. And the shipping had taken time, so I had created a new repository from my backup. But since my working set was at a different version than my backup repository, svn wouldn’t let me checkin. Frustrated, I started looking at other vcs.

What got me first looking at git was the google talk by Linus Torvalds. I then read up at the current state of dvcs before I started testing out git, and I was hooked.

What I find interesting is that git feels ‘natural’. The impact on my development process is minimal. As an example, to create a tag in svn:

svn copy svn+ssh://server/path/to/project/trunk svn+ssh://server/path/to/project/tag/{version}

The same command in git:

git tag {version}

Branching is similarly easy in git. But I think the main advantage is that I now can I have multiple repositories for the same project.

My current work process is like this:
edit edit edit
checkin into local repository
edit edit edit
checkin into local repository
happy state
push to private server
edit edit …
once stable state
push to public repository

At at any time during the editing phase, if I’m unhappy with the track I’m on, I can always throw out the changes without messing up my private or public repository.

I really think you should at least take another look at the dvcs and see if it’s something for you.

[1] Wincent Colaiuta’s development blog
[2] Dave Dribin’s Choosing a Distributed Version Control System
[3] Ben Collins-Sussman’s The Risks of Distributed Version Control