Scott James Remnant

Like any sensible software developer, I have a close relationship with revision control systems. In my previous job, I was an SCM Engineer (see Software configuration management) which meant I had an even closer relationship than most, since we were running the CVS servers and actively using them to track changes and deployments.

We all know, deep down, that revision control systems shouldn’t exist. This kind of thing should be inherent in the design of the operating system, through standard file and filesystem formats. The OLPC interface is making some headway towards that, but for the rest of us, it means using a revision control tool throughout the development process.

Unfortunately, even though the tool is expected to be the most-used command on your system, very few of them are particularly easy to use. Thus there’s a large learning curve, and people become religious about their choice since they have invested significant time in using it.

Just to spice the mix up, not only will people religiously defend their choice of revision control system, but they’ll do so while actively hating it.

In the beginning there was CVS and we all thought that it was pretty good. It was based on the simpler RCS and shared a file-format with it, but introduced control of directory trees and remote operation.

Actually, in reality, CVS wasn’t that good. Its command set could be a little strange and inconsistent (e.g. it’s not possible to diff between two dates on a branch); the support for branching assumed that all branches would be merged into the mainline, and only once; and nobody ever really knew how to create a new project in a repository (tip. cvs import is wrong).

But we all used it anyway, and we muddled through. It did have some good features; it was simple, fast and pretty reliable–when it did break, you could usually fix the repository yourself. And most importantly of all, we understood how to drive it.

And so it was for many years, until Subversion (SVN) came along. Subversion intended to be “a better CVS”, perhaps this goal should have made us suspicious at the time since CVS was already being a pretty good CVS by itself; unfortunately we hated CVS so much we flocked to the new system in hope.

In hindsight, Subversion didn’t really improve on CVS much at all. In fact, arguably, the only real improvement was the addition of atomic commits (in CVS, each commit is per-file, so it’s manual labour to work out which change was made to two files at the same time).

(Its support for branching, tagging, copying, renaming, etc. were no better than CVS’s when done in the repository by hand.)

The cost of this single new feature was a much more complicated interface (with two separate commands), a backend that tended to break down weekly and a lethargic slowness to its operation.

Most people I know now justify their use of Subversion instead of CVS by “Subversion is maintained, CVS isn’t” which is a somewhat self-fulfilling justification.

While the mass conversion to Subversion, and ensuing disappointment and frustration, was going on; something new appeared on the horizon: Arch.

Arch was different, it broke one of the core assumptions of revision control, that of the repository as a cathedral. In CVS, and Subversion like it, if somebody wants to modify your code (even if on a branch) you need to give them access to your own repository. In some cases (especially with CVS), vast access control and permission structures would be in place to ensure proper behaviour.

With Arch, you don’t; all you need to give to anyone is read access. Anybody can make their own branch by copying yours and committing to their own copy.

This model also necessitated fixing a long standing problem that CVS had; Arch has repeatable (smart) merging. If you merge from a branch, you can merge again later, and again, and again.

Arch made this possible through each commit (changeset) having a globally unique identifier; made from the branch’s own globally unique identifier and the changeset number in the branch.

Unfortunately while this was a massive step in a new direction, Arch had an absolutely terrible user interface. Its command list was terrifying with over 100 commands, many of which had multiple word names (tla set-tree-version). It exposed too many of its own innards, and expected you to learn them. It also forced baroque file naming semantics on its users and strange policy (though shalt not commit without first running “make clean”).

Efforts were made to improve Arch’s user interface through projects such as baz, but they were always to be doomed from the start.

We’ve since seen an explosion of new revision control systems; Monotone, Darcs, Git and Bazaar.

What’s especially interesting is the commonality between these systems. They are all “distributed” like Arch, though they also all discard the strange “unique branch identifier” convention and instead simply assign a unique identifier to each file or commit.

This means that they all support personal branches, and by necessity all support repeatable (smart) merging.

So how do they differ, what are their killer features and killer problems?

Monotone is all about repository integrity, ensuring that every commit is both authorised and intact. It pays for this with a severe lack of speed.

Darcs is based around a “theory of patches”, a branch is not made up of its history but by the collection of patches in it. Unfortunately this often breaks down, and darcs frequently gets stuck calculating even trial and commonplace branch models.

Git is very strange to me; its killer feature appears to be the speed at which it can handle very large trees, but the interface is as insane as Arch’s was. It is heavily optimised for the “I only apply patches” development model, at the expense of ordinary development models (it shares an issue with Arch where calculating annotations on an individual file is an expensive operation).

What about Bazaar? Its killer feature is that it is designed to work the way you do. The command set is relatively small, and each of them works in the most obvious manner. It also supports plugins so that you can always implement your own workflow.

Of all the revision control systems, it’s the only one (that I’m aware of) that supports both distributed and centralised workflows (and lets you go distributed when you need to, e.g. when you’re on a plane).

Here’s a few examples of how Bazaar’s command set works the way you do. To start managing some code in bzr:

$ cd myproject
$ bzr init

To add the files, copy in your usual .bzrignore file and just add everything:

$ cp ~/bzrignore .bzrignore
$ bzr add
added foo.c
added bar.c

Check the output for mistakenly added files, adjust .bzrignore and remove the file with bzr rm.

A common operation is realising that the commit you’re about to make should really go on a new branch for now:

$ cd ..
$ cp -a myproject myproject-foo
$ cd myproject-foo
$ bzr commit

A copy of a Bazaar branch is a different branch, you can commit to it separately. There’s a bzr branch command for it too (which deals with issues such as bound branches, checkouts, etc.) but it’s nice to demonstrate that Bazaar does what you’d expect even when you don’t use its own commands.

Pulling changes from another branch (where you haven’t made any modifications yet) is easy:

$ bzr pull ../myproject

As is merging (when your branches have diverged):

$ bzr merge ../myproject

One particularly nice feature is that after a merge, you see the merge as a single commit and it can be treated as such; but it also has the set of merged commits indented under it–you can examine these as individual commits as well!

What’s the downside of Bazaar? Well, it’s not the fastest system (but by no means the slowest), for small to medium sized projects this is never an issue but may be for extremely large projects–fortunately the developers are improving its performance all the time!

But that doesn’t matter; it is, honestly, the first revision control system that I don’t hate.

Two lessons booked today, one before lunch and one after lunch. The long term forecast hadn’t looked good, and I thought it’d be a good idea to try and cover the weather. Turns out that my hunch was right, the weather really wasn’t looking that good this morning, but looked like it might clear up towards the afternoon.

The original plan had to be to cover slow flight and stalling today, but the weather wasn’t going to be good enough for that; certainly not good enough for stalling.

John decided that the best thing would be to go up and do some revision of turning, especially while climbing and descending; and an introduction to slow flight. Then after lunch, if it had cleared up, finish up slow flight and move on to stalling.

We had plenty of time, because the previous student had cancelled; and as it turned out, the one between my lessons and the one after cancelled as well!

Victor November as usual, but today spotted a problem doing the checks; a screw had come loose on the left wheel spat and had to be tightened before we took off.

Handled the take-off again today, a fairly easy one along Runway 36 remembering to turn to 030° afterwards to avoid overflying Charlecotte who don’t like it when we do.

First bit of revision into climbing turns accomplished then, and again as we turned onto downwind before leaving the circuit. Held the course south, and did some descending and climbing turns over Shipston-upon-Stour before heading west.

Cloud wasn’t going anywhere, and the horizon was really indistinct which made holding a reasonable attitude quite difficult, let alone turning on it; but managed to muddle through.

Next up was an introduction to slow flight. This is basically slowing the speed right down while holding the altitude, keeping the nose very high. Brought the power back in a couple of stages, and after each one it was increasingly harder to hold the aircraft’s attitude and required huge movements of the controls.

Stall warner sounded as we got particularly slow and it was time to recover, so lowered the nose and increased to full power, climbing out of it.

Practiced those a couple of times to get the feel of it right. Then time for a bit more practice at some turns, had the aircraft in a descent when John asked me to turn, which I did; but I’d forgotten to get it in trim first, as a result made quite a mess of turning out and levelling off. Bugger.

In fact, I felt that the weather was throwing me off completely so we headed back to the school for lunch, with the hope that it’d at least clear up for the afternoon session.

No such luck though, after a decent lunch and some time in the briefing room covering the procedure for stall recovery just in case, the cloud wasn’t going anywhere. It had lifted a bit, and there was a spot of blue sky around Wellesbourne, but no more than that.

Visited the control tower to see what it was like, and they weren’t too keen on it either. Someone was up doing their skills test, but they’d headed off to the east for some decent weather.

Definitely wasn’t going to be doing any stalling today, and John asked me what I wanted to do.

Since it had improved slightly, and I wasn’t happy about mucking up some of the basics in the last lesson, I asked whether we could go up again for some revision of climbing, descending and turning.

He agreed that was a good idea, so that’s what we did. Another take-off, climb up through the circuit and out. He then set me a few exercises such as turning to a particular place, getting us there, changing altitude and turning onto a new heading, flying there; changing altitude again and turning towards home before a standard over-head join into Wellesbourne.

The improved visibility and much more relaxed nature of the flight, not having to learn anything more, really put me back at ease and I found that I was able to do the exercises much more confidently than I had before.

In the end, quite a productive lesson despite the weather. Several things to read up on for next week, since depending on the weather it’ll be more slow flight, some stalling or maybe even a first circuit or two.

P/UT Hours Today 1:30, Total 6:50

Wasn’t sure what I was going to be learning today! I’ve reached an interesting point in the course where there’s any number of lessons I could do, depending on the weather.

Ideally this lesson would be some revision of slow flight, and an introduction to stalling; but stalling is going to require a decent enough cloud base (over 3,000ft!) to be able to do it.

Otherwise if neither of those are possible, it’d be starting on circuits and learning how to land. I feel a bit like Indiana Jones at the moment; when people find out that I’m studying for a PPL, they usually say something like “I didn’t know you could fly?” to which I have to reply “Fly, yes. Land, no.”

Weather didn’t look too bad looking out of the window, but got increasingly worse as I drove to the airfield. Didn’t look like stalling was going to be happening today, the cloud was coming in far too low. John agreed and decided that we’d do the briefing on it, but would probably just do some revision on slow flight and complete that exercise.

A new plane today, G-WAVA. A notorious poor starter, but Stephanie claims has now been fixed! Not sure about that, it definitely didn’t want to start this morning! Probably wasn’t entirely happy about having needed duck tape stuck across the oil filler cap. While doing the checks, I’d been unable to get the cap to stick back down again.

An odd cross-wind today so we were on the much shorter Runway 23, since this was a bit of an unexpected challenge, John handled the takeoff while I followed him through. Once in the climb, I had control again and we did some practice of turning climbs as we headed out of the circuit and down to the South.

Overhead Shipston (they must really hate the sound of small aircraft there, we always seem to be flying in circles around them!) John asked me to bring the power back and hold the attitude to keep the height; more power back, more holding of the attitude and again until we’re only just a few knots away from the stall; once more and the warner sounded, so nose down and full power to recover, climbing away.

A few practices of this, before going again with flaps and then practicing turning while in slow flight. Turning has the extra challenge of having to nudge the power in to avoid a stall, since the turn increases the stalling speed whilst simultaneously decreasing the speed!

Didn’t quite nudge hard enough on a turn to the right, I’m sometimes a little too gentle with the controls when I need to be rather more forceful with the power at times.

I’ve also caught myself adjusting power and watching the RPM meter, rather than listening for the change in tone. Made a mental note to stop that, and found it much easier for the rest of the flight. Had been doing it turns too, and watching the attitude indicator; oops! Bad habits creeping back while I’m busy learning new things.

A few more practices before heading back home, as the rain came in; which we caught over Stratford as turning to begin the overhead join. This was a bit more interesting, since we were in a different pattern and turning at different times to what I was used to (having normally joined for Runway 36).

P/UT Hours Today 0:45, Total 7:35

I really wasn’t sure whether the weather was flyable looking out of the window this morning; the forecast hadn’t been that promising, but today’s METAR was a little better — at least it gave me some room under the cloud.

Phoned the flying school and was told that the cloud base was pretty high, but that wind was rather gusty down the slot. Flyable nonetheless.

Got there, and John had decided it was too gusty to start on circuits; he wanted it rather calmer for my first landing attempts. Instead he’d been down to the South-West with the previous student, and there was a good couple of holes in the cloud, so ideal for stalling!

Gulp.

In reality, the idea of stalling shouldn’t have made me that nervous as we’d been close to the stall with slow flight the last couple of lessons and had already practiced recovery. Nonetheless the thought of deliberately stalling the plane and losing the precious lift wasn’t exactly making my day. Two hours of it to do for the course though, so brave face!

Checked over the plane, largely okay except for a screw loose on the wing that John had already spotted during the previous flight, quickly fixed and taxied off down to the hold. Runway 18 today, haven’t used this one in a few weeks, so a different place to test the brakes and rudder, but remembered.

Have noticed that I’m largely being left to do the checks and pre-flight myself now, and that they’re becoming close to second nature. Still noting that I tend to pre-empt the FISO in shortening the callsign, and deliberately left a space on my kneeboard for writing it down once told it. Didn’t help much, since I ended up forgetting to shorten it and confusing myself, something to work on I think.

In fact, this time John didn’t just let me do the checks and pre-flight, he left me to it all the way through the take-off as well! I’d gotten a little used to his voice talking me through it the last few times, so I compensated by talking myself through it instead.

It seemed rather busy to me, the fact that once off the ground we basically ended up going sideways with the wind didn’t help; and I was using up all my brain-power to keep the plane climbing and in balance. John was entirely happy, and thought I coped brilliantly with the challenge, so that’s ok then.

Bumpy climb all the way to Shipston, where there was a nice hole in the cloud as promised. More than enough room to climb to over 3,200ft for the exercises.

Some revision of FREDA checks and HASELL checks, then handed control to John so that he could demonstrate a clean stall and recovery with power. Not as dramatic as I feared, it seemed to take ages to actually stall, and then the nose simply pitched slowly to the ground as we lost height. Hold it down, full power, and pick your stomach up later as the plane regains height.

My turn now.

Regain the height, HASELL check then reduce power to idle. Hold back on the column to keep height, pull back on the column, heave back on the column. Speed washes off quickly, then at some point the stall warner sounds. Still pull that column back, with all the strength you have, as the plane tries to pull it away from you and eventually it goes limp and the plane pirouettes down. Column forward, full power, wait for a good speed, and collect the stomach. “Good,” said John, “minimum height loss, well done!”

Maybe that wasn’t so bad after all. Regained the height, and a full turn to keep out of the cloud and had another go. Minimum height loss again. One more then; this time pulled out a fraction too early so the stall warner sounded, I reacted instantly releasing the column pressure and John was pleased that I’d simultaneously demonstrated to myself how to repeat the stall during the recovery, and how to avoid/recover from it.

Cloud was coming in a bit, and we were having to turn in it to get away and there just wasn’t enough of a hole left to carry on. Descended down underneath the cloud base again, which turned out to be 2,200ft; and set a course for Stratford.

Flew the pattern for the overhead join, but the FISO decided to throw me a curve-ball; on announcing that we were descending deadside I got told “use callsign Robin Victor November”. Turns out that there was a helicopter flying around clashing with our usual callsign.

Crosswind made it a little tricky to get the plane to descend and turn at the same time, so John took control to get us in the right direction before giving it back to me for the rest of the descent and join.

Passed over the threshold and heard radio traffic from someone announcing downwind, and looked out for them since we would shortly be turning onto downwind ourselves. Spotted them in front of us, but about 1,000ft higher! Quick sanity check ensued, look out of the windows to see whether we were too low, and check the QNE and altimeter. All ok, he must have been too high. This must have been the case, since by the time we turned onto base, he was rather lower.

Handled the turn onto base and start of the descent myself, up to the turn onto final; but the crosswind was too much to get the attitude right so John took over for the landing itself. “A bit unfair for your first landing to be in this,” he said while wrestling with the plane himself!

Control back to me on the tarmac, checks and taxied to the fuel bay to fill the plane back up for the next student. No wait this time, so easily done and back to the school.

Next week will depend on weather; if it’s relatively calm, we’ll be starting on circuits (and landings!) otherwise if there’s a good cloud base or hole, it’ll be more work on stalling, especially different types of stall.

P/UT Hours Today 0:40, Total 8:15

I think I’ve just invented a new sport…

Everyone knows the game of Googling your own name, and finding out all sorts of fascinating things that you have forgotten or didn’t realise had made it onto the Interwobble.

Here’s a new twist, use the Internet Archive Wayback Machine instead and read through things like old versions of your homepage.

I’m honestly shocked at just how much incriminating material I’ve found, both from my own website and segfault.org

This comment on my site from Leonard Richardson and my reply especially amused:

What percentage of the time are you drunk? This is to settle a bet.

Okay, well on an average week I guess I go out for 3 nights. Friday night starts at 5:30 and ends 12 hours later, the other two days would be probably from 9:30 to 2:30am, so 5 hours. So we can say I spend 22 hours innebriated. Just under a day, or 13% of the week. Some weeks that might be as much as 25% to 30% I guess tho.

Who was the bet with, and more importantly, who won?

This explains a lot …

Continuing my mission to put together a kick-ass team to develop the Ubuntu Desktop, the following position is now up on the website:

Posting Date & ID: September 2007 UDD
Job Location: Your home with broadband. Some international travel will be required.
Job Summary: To adapt and develop the GNOME desktop to improve the Ubuntu user experience.

Key responsibilities and accountabilities:

• Use open source development methods to create, select and adapt software to produce innovative user experiences and address the common problems of desktop computing
• Extend the desktop platform as necessary to support development
• Work with designers, artists and other developers to develop ideas and complete the project
• Involve the community of development projects, teams and Ubuntu supporters to incorporate a range of perspectives and ideas
• Take ownership of many aspects of the desktop user experience (”look and feel”) in Ubuntu
• Follow projects and trends in user interface design in the open source world, integrate the best technologies into Ubuntu and ensure their quality
• Analyse, triage and respond to bug reports

Requirements skills and experience:

• A keen and insightful eye for user interaction
• A passion for intuitive, usable and visually appealing interfaces
• A strong desire to produce distinctive ideas that stand Ubuntu out from the crowd
• Experience with the GNOME development platform and desktop environment and technologies such as GTK+
• Some experience with mainstream graphics technologies such as OpenGL and Cairo in the C programming language
• Ability to be productive in a globally distributed team through self-discipline and self-motivation, delivering according to a schedule
• Familiarity with open source development tools and methodology, especially those in common use for Ubuntu and Debian package maintenance

How to apply

Please send a cover letter and CV with references to hr@canonical.com. Please indicate in your submission the role for which you are applying. We prefer to receive applications and CVs/Resumes in either PDF or plain text format.