maelstrom

cvsup

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.