On the Cusp: Distributed Source Control

I’m a die-hard Perforce lover, having first encountered the tool in 1998 while interning at Silicon Graphics in the bay area. We adopted Perforce at E-Quill and had no regrets. My current employer, Microsoft, secretly uses its own custom build of Perforce; apparently they acquired a license some years ago when they realized that SourceSafe didn’t scale past one developer.

Perforce is both powerful and deep, yet it has a remarkably simple command-line exposure that puts this power within even a new user’s grasp. It’s also incredibly fast even for complex operations.

Despite these great points, it seems clear to me that Perforce provides developers with a poor model in many respects:

  • I regularly find myself making multiple copies of our team’s primary source depot so that I can experiment with different changes.

  • I sometimes want to share changes with just a few co-workers, and I can’t.

  • Branching is bizarre. Branches inhabit the same global path space and require careful creation of “path specs”. This feels conceptually wrong, like I’m nearly duplicating my entire source tree rather than providing a different historical view on top of it.

  • There isn’t a meaningful story for workflow; my checkins go straight into the team’s depot, without first having to pass tests, or peer review. I’ve seen some custom tools inside Microsoft to provide a workflow on top, but their underlying interactions with Perforce seem unsatisfying. This appears to be a weakness of the tool itself.

Most of these issues seem to have the same root cause. Fundamentally, Perforce seems broken to me because it requires a central repository. I’m not entirely clear on what a distributed variant of Perforce would look like, but it’s certainly got to be viable, and worth exploring.

Update: A friend pointed me to DARCS, a distributed source control system. It’s maybe theoretically interesting, but fundamentally it seems like source control built by mad scientists. I’m convinced you won’t need to be a mad scientist to understand and use distributed source control, assuming the right model is found.