maelstrom

$ git fetch http://git.sv.gnu.org/r/coreutils.git
Fetching HEAD from http://git.sv.gnu.org/r/coreutils.git using http
error: Request for fe3fbf2f543e4b3a532c2b0bfd2fe18c9048caae aborted
git-http-fetch in free(): error: chunk is already free
Abort trap (core dumped)

Why did you write git in C? Because Linus told you to?

Within a few days of the destruction of my T40, I got a T43 from a guy on craigslist. The left control key promptly broke so I swapped it for the right one. There's relatively little info out there about how to assemble and disassemble keys, so here's some info on the process. Before we begin, get out your jeweler's eyepiece...

You can pry off the key face gently as described here, just push away from you and up with a flat object. The face snaps into a cage mechanism consisting of three parts: a top plate and two wickets which anchor it to from the north and south respectively. Each wicket has a bar that wraps over the top plate, and two legs with pegs that secure it to the keyboard bevel. Viewed from the east or west sides, the wickets cross over each other, making an X. There is enough play in the cage's anchoring that you can squish the whole thing down flat. The only thing that impedes you is a little rubber spring glued to the keyboard bevel. This spring is primarily responsible for that distinctive Thinkpad key feel.

By squishing the cage flat, you can hook or unhook the wickets. To reassemble and replace a key, I found it easiest to build the cage first. Start by crossing the wickets--they are fitted to each other. While pressing the X sides of the cage in, you can slip in the face plate. Don't put on the key face yet. Attach the cage to the keyboard bevel by putting it in place and hooking in the south wicket's legs first. Getting the north wicket in is a bit of a stretch. Flatten the cage by pressing down on it until the north legs slip in. Now you can attach the key face by setting it on top of the cage and applying gentle downward force. You should hear it snap.

Let's face it: cvsup(1) is mad lame, but it's about the best thing out there. These days, it seems like most unix projects expose their packaging system at the heres-how-to-build-from-source-for-me level. Some do it more elegantly than others: let's hear it for bsd.ports.mk...down with dpkg-buildpkg and fakeroot and all that craptacular stuff. Bonus points if you can check out the whole thing in one source tree (+1 BSDs, Gentoo) instead of scattered repositories. Even bigger bonus points if you don't have to inflate a monstrous working copy to check it out, and yet still track what you got. +1 BSD in that category thanks to cvsup.

Yet it's still crap. It's crap because cvsup doesn't need to exist. It updates the whole ports tree and even compensates for directories getting moved around. But you'd get that for free if FreeBSD would just migrate the ports tree to subversion. cvsup is just duct tape to make CVS kind of tree-versioned. Migrating to svn, however, won't happen anytime soon, because the kernel is in that same repository with the ports tree...and who wants to make the process of checking out the BSD kernel sources dependent on a trendy project like subversion? It's bad enough already that you need CVS to do that.

I hear you raising an additional objection: subversion working copies are a hog, both in space and time, so cvsup wins out on the performance axis. And I agree. SVK doesn't help you much here, as it contributes enough of its own flakiness to offset the working copy savings.

So what I'm really saying is, all of it sucks. I haven't seen something which doesn't suck yet. What the world needs now is a subversion minus the bullshit: a super-performant version control system that just presents itself through the filesystem for the most part. No not ClearCase...masochist. You'd still check out a working copy and make changes to that. But checkout would be a simple rsync operation against the repository-as-served-up-via-the-filesystem (FUSE?). The rsync could be local or tunneled over the network if the repository was hosted remotely. All you'd need is the ability access the full tree as a snapshot at every revision via e.g. /mnt/repository/$rev/.

Could you do this and still make it performant? A lot would depend on the filesystem module and the storage mechanism. Leaving kernel space to go talk to a database on a socket might result in heinous overhead. Just having a "real database" in your corner doesn't mean you win the fight either. At first I thought a "real database" was the solution to subversion's performance scalability problems, but the more I thought from scratch about a better schema, the more I started to understand. Supporting cheap tree copies and versioned trees at the same time is tough.

$ perl -we 'print keys %{{}}'
Unmatched right curly bracket at -e line 1, at end of line
syntax error at -e line 1, near "%{{}}"
Execution of -e aborted due to compilation errors.