Improving Software

As a longtime fan of  FogBugz, I’ve been dying to start moving some of my personal projects over to Fog Creek’s Kiln. Although I won’t get much use from Kiln’s code review functionality as the lone developer on these projects, I like the idea of storing my code in the same tool that I use to manage the workflow and other meta-information about those applications.

I’d like to say this preference is based on the potential value-add of the integration features between Kiln and FogBugz, but frankly it is more about my core belief in keeping things as simple as possible.  Also, I make a habit of not storing anything that I can’t afford to lose on the hard drive of my development computer where backups are a tad sporadic. So using a hosted source code repository is attractive in that respect also.

I was sold. All I needed to do to kick off “Project Simplify” was to import my source code into Kiln from my Vault repository and … hmmm. It seems that Kiln is based on an SCM tool called Mercurial that I was unfamiliar with. No worries, I’d adapted to new source control tools before, it would just be a matter of translating the jargon from Vaulteese to Mercurian, right?

Wrong.

As it happens, distributed version control systems (DVCS) such as Mercurial represent a considerable paradigm shift from their traditional centralized cousins. At least this is what its evangelists are saying. Despite the claim on the Mercurial Home page that it is “Easy to Learn”, all the anecdotal evidence I’ve seen seems to indicate a significant learning curve.  However, it also appears that once DVCS finally clicks, it is extremely popular with developers. That’s enough for me, I’m still on board, but cautiously optimistic.

So I downloaded and installed the “Kiln Client”, a bundled copy of Mercurial, TortiseHg, and a few Kiln specific extensions, and started working my way through Joel’s Mercurial Primer. Unfortunately, it still wasn’t clicking for me. I got the mechanics down pretty quickly, but I still couldn’t GROK what all the hoopla was about or how I should adapt my current workflow. Things got hectic at work, so I set it aside until the Fog Creek 2010 FogBugz and Kiln World Tour came to town promising to drop some knowledge on us poor schmucks who hadn’t come to Jesus yet.

It is no secret why Joel is hawking Mercurial so fiercely given that to have any use for his new Kiln software you pretty much have to first migrate to Mercurial. Although I appreciate his zeal, I am admittedly skeptical of his decision to tie the fate of Kiln to a technology that (1) is still in the early adopter phase; (2)  involves a substantial barrier for his customers to buy his solution; and (3) requires a religion change for many users of competing SCM tools.

Still, I’m not going to pass up on free training, even if there might be a self-serving agenda behind it. So I went and I think I am better off for it, but I’m still don’t feel confident that I fully understand the use case. Maybe it is because DVCS is always pitched as the solution to the nightmare that is branching/merging in Subversion. I haven’t used Subversion for years, sparingly use branching in Vault  and work on a relatively small development team. Perhaps if I was working with hundreds of developers on big OSS projects, that have seen high adoption of DVCS tools,  I’d see the appeal more easily, but for now it is still evasive.

One aspect that I totally get is the idea of a two phase commit. I may not have been involved in a monster merge, but I have on numerous occasions had developer’s machines go down taking several weeks worth of uncommitted code changes with them. The idea of being able to check-in code privately resonates very much with me. However,  this feature (“Shelving”) already exists on existing centralized version control systems, e.g. Vault. Further, most DVCS workflow examples I’ve seen seem to encourage keeping the working version of the repository on the developer’s workstation, which doesn’t seem to provide much protection from data loss for uncommitted changes.

I also have a very positive opinion of the notion of revision control on entire change-sets as opposed to individual files, but again, while this is a common feature of DVCS systems it need not necessarily be unique to those systems and could be added to more traditional centralized SCM tools.

Having said all of that, I’m not giving up yet, but I’m still waiting for that eureka moment where the necessity of DVCS becomes so obvious that I can’t imagine ever going back. For now, I’ll use it for my projects that I want to store in Kiln and continue to use vault for my other projects. If you have a really good use case for DVCS or a really good way of explaining the benefits that will help me along, I’d definitely appreciate you leaving a comment on this post. I want to believe!

Filed under: The Software Development Process | Tagged: DVCS, Kiln, Mercurial, Source Control, Vault |