svk

A week or so ago I spent several days trying out svk. svk layers distributed version control over subversion's centralised revision control model.

The good:

• It's very easy to learn svk if you know svn (and thus if you know cvs), just a few added and a very few changed commands. Oddly, bazaar-ng seems to be converging on the same UI from an arch heritage; even the new commands behave similarly.
• There are no more .svn directories in working copies; in fact working copies have no extraneous files at all, which is marvelous.
• Even working with local branches of centralised repositories has been made nearly as easy as I can imagine it could be; it's possible to commit a change locally and merge it to upstream in a single, simple command if you want to. Fully disconnected development with subsequent updates or merging to/from upstream works well too.
• It can apparently be made, with some difficulty, to mirror cvs repositories as well, which would be great for dealing with those laggard projects, like debian-cd and the debian website, that still use cvs.
• There's a nice responsive community around it; the lead developer is easy to get in touch with.

• There's no support for svn:externals. Since I use externals a lot, this makes checking out my entire home directory using svk quite tricky. I found a semi-solution using symlinks.
• A few commands are subtly different from subversion. For example, svk annotate does not display history from the central repository by default, only from the local branch, unless you add the -X switch. This can be confusing.
• If you want all the history of a repository, you have to mirror it, and this takes just as much space as hosting a full copy of the repository. For me that's something like 3 gb of mirrored svn repositories. This more than offsets the space saved by no .svn directories. Of course you can get away with only mirroring the last few revisions of trunk and maybe save a lot of space, but that is not really an option for me since I need the full history.
• The process of mirroring a repository is slow. It has to replay every revision into the local svn repository. When you have 50 thousand revisions, that takes a while. I'd be interested to know if other distributed revisions control systems have gotten around this; one test tla checkout I tried seemed to suggest they've not.
• The svk command is also a bit slow to start up due to using a slew of perl libraries.

• I managed to find one repository that svk cannot mirror at all; it crashes.
• Mirroring another repository made svk consume over a gigabyte of memory and OOM. I even OOMed svk once with a svk annotate -X command. In general it seems that it needs a lot more work done to scale to moderatly large repositories such as some of the ones I work in.

svk is not out of beta yet, and I hope that eventually some of my problems with it will be solved. So far I cannot seriously consider using it for managing my whole home directory on my laptop; I can see using it for some individual, smaller projects, if I need the disconnected operation.

When I switched to subversion, I doubted that it would be the final word in revision control systems for me. I hoped that as better/different systems came along they'd follow the lead of subversion (and others) and provide ways to import data from the revision control systems they supplanted. svk has both confirmed that feeling, and made me worry, since I've begun to realize that perhaps importing past change history is not enough; the newer systems have to be scalable enough to deal with my own, constantly growing, repositories.