Open Source means never having to bother with error handling

A common error condition leaves your data in an inconsistent state and leaves temporary files all over the place? Just another day in the open source world, I’m afraid.

Now, the GNU Arch revision control system has some pretty nifty features. In particular, it makes creating and merging multiple branches of a program’s code base pretty easy, unlike, say, CVS. However, its error handling (and I use that term loosely) is downright infuriating.

I’ve recently started on a branch of Rhythmbox to add DBus support. Since Rhythmbox’s source is in a GNU Arch repository, it’s pretty easy to create a branch of it in my signed Arch repository on holly, and work on it on kryten while I’ve been away this week. (Reminder: holly == desktop, kryten == tablet.) So far, so good.

Now to commit my first set of changes. Should be as simple as a tla commit, right? Unfortunately, I had forgotten to install GPG on kryten, so it bombed out when it tried to sign the changeset. OK, no harm, no foul. I just need to aptitude install gnupg, copy over my keyrings, and try to commit again:

paul@kryten:~/rhythmbox-dbus$ tla commit
M  shell/rb-shell.c
M  shell/main.c
M  configure.ac
arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
    tree: /home/paul/rhythmbox-dbus
    revision: kuliniew@purdue.edu--2004/rhythmbox--dbus--0.9--patch-1

Say what? The original commit attempt seems to have left the archive in an inconsistent state. Apparently there’s still some lock file somewhere that’s preventing the commit from going through (though “internal error” is a bit scary). And no suggestion what I should do to fix the problem. And as an added bonus, Arch leaves behind a temporary directory named something like ,,commit.rhythmbox--dbus--0.9--patch-1--kuliniew@purdue.edu--2004.1091912373.3033.6 in the current directory. Yes, the name starts with two commas. Thanks for that.

Google, as always, comes to the rescue. A search for that error message turns up instructions for fixing the problem. To be fair, the error message Arch spit out after the initial commit (which had long since been scrolled out of any terminal buffers) suggested that this might be necessary, though you’d think that it’d just go ahean and clean up after itself in the first place, especially since the authors of the program obviously knew about this problem!

But this should take care of the problem, right?

paul@kryten:~/rhythmbox-dbus$ tla lock-revision -b patch-1
lock-revision: invalid revision name (patch-1)

Oh, apparently Arch can’t seem to figure out the full name of the revision I’m trying to work with is, even through seemingly every other Arch command can figure it out. Let’s try being more specific:

paul@kryten:~/rhythmbox-dbus$ tla lock-revision -b rhythmbox--dbus--0.9--patch-1
lock-revision: unkown lock state for kuliniew@purdue.edu--2004/rhythmbox--dbus--0.9--patch-1
   (lock was in transition -- consider retrying)

OK, read that error message again, even ignoring the spelling error. The command to fix locking problems in the archive is complaining that it can’t figure out the lock state. WTF? Of course the lock state is screwed up; why else would I be running tla lock-revision -b to break any outstanding locks?! You’re supposed to fix the problem, not complain about it!

Googling for that error message turns up an explanation of what’s really causing the problem. Apparently the directories used to manage locks internally within the archive disappeared. Shouldn’t tla lock-revision -b be able to fix this problem itself? So I get to dive down into the horrible nest of long-winded directories (/home/paul/archives/2004/rhythmbox/rhythmbox--dbus/rhythmbox--dbus--0.9/patch-1/++revision-lock/+contents is what’s missing (yes, those are plus signs)) to fix the problem manually.

So let’s recap. Arch couldn’t handle the case where a call to an external program (gpg --clearsign) failed, and as a result completely screwed up the locking directories in the archive and left behind obnoxiously-named temporary files in the current directory. The authors knew this can screw up the archive’s locking (it’s certainly a FAQ, judging from Google), one of Arch’s error messages even acknowledges this, but doesn’t actually do the necessary clean-up itself. Plus, the locking directories are so screwed up that they require manual intervention in the archive itself to fix the problem.

For some reason, the brittleness of GNU Arch in the face of commit problems reminds me of this ATHF quote:

Oglethorpe: The Remonster can only be killed by stabbing him in the heart with the Ancient Bone Saber of Zumakalis.
Emory: Or probably his head or lungs too, just stab him where ever really.
Oglethorpe: And the saber probably doesn’t have to be bone.
Emory Yeah really just anything sharp just lying around the house.
Oglethorpe: Ya, You could poke him with a pillow and kill him.

Comments are closed.