Moving to Mercurial
Before we ever announced Conary, we tried converting from CVS to Subversion. We were not happy; the conversion wasn’t great, but much worse was the corruption in the db back end (I know there’s a filesystem back end now); we decided that we could live with CVS at that point, and that it just wasn’t worth the trouble to change. I understand that Subversion has improved since then, but one of the things we decided was that if we were going to change, we really wanted to move to something that allowed disconnected operation (for those cross-continental plane flights…).
A few months later, I think shortly after we announced Conary publicly, we tried migrating to Arch (tla). The conversion was incredibly slow, and we still weren’t happy. Not saying anything bad about Arch, either; we just weren’t happy with it in our environment and with our practices. I don’t even remember now all the things that we didn’t like about it well over a year ago.
When Bitkeeper took away the “free beer” bk licenses for Linux kernel development, two projects started at the same time: git and Mercurial. I was particularly impressed with the approach that Mercurial took, not only from a technical perspective, but also from a social perspective. Mercurial developers quickly set up a wiki that contained enough information that someone who was not already familiar with the general distributed disconnected changeset-oriented version control model could quickly become productive with mercurial. From a technical side, its repositories are about a tenth the size of git repositories, it’s implemented in Python with a few small C extensions (sounds familiar!), and it enables web browsing of archives “out of the box”.
So in August, I learned how to convert CVS archives to Mercurial archives (and wrote more detailed information on the process for the Mercurial wiki) and did a sample conversion of Conary’s CVS archive to Mercurial. It had a few rough edges, but it basically worked. I packaged up the new 0.7 release of Mercurial, but we weren’t really interested in moving version control systems right at that moment; there was no pressing need to spend time on it, and not everyone was convinced that Mercurial was ready for the job quite yet.
Yesterday, we ended up with a namespace conflict between anaconda and conary that unexpectedly required us to completely rearrange where Conary put its files. Suddenly, a version control system that handles file renames became a critical priority instead of a would-be-nice-someday thing. I found out that things had changed so that my conversion process didn’t work, so I had to learn what to do and change my Mercurial wiki writeup of how to convert, and ended up doing two full conversions before we had done it right. Then there was the matter of infrastructure, things like setting up commit messages. I was very motivated to fix that, because until I fixed it, I had to manually generate all commit messages! By 2:30 this morning, things were finally sufficiently functional for me to go to sleep.
Mercurial is going to change our development process, and I’m sure we’ll have some bumps in the road, but it’s also going to make some things a lot easier, and despite lack of sleep I’m excited about this new model.