Benefits from a real world switch from CVS to darcs

by Mark Stosberg

Background: Our usage model and reasons for switching

Each developer had their own code copy of the repository. We used an "alphasite" for internal quality reviews, a "betasite" for client work reviews, and a production copy for the live website.

We weren't trying to maintain branches in CVS. I was aware they are one of the hassles of using CVS. If we wanted to share code with each other, or update the alphasite, the betasite or or the production site, we would commit to CVS HEAD and update the desired location.

This worked OK, with some coordination among ourselves about when it was a good time to commit or update and when it wasn't.

The problem was the exceptional cases: While some work was being previewed on the alphasite or betasite, a high-priority request would come in that should be fast-tracked to production, ahead of the work that was already committed.

We handled that with a little bit of luck and a fair amount of headache. If we were lucky, the fast-track change affected different files, and only those would be updated on the live site. If we weren't so lucky, some one-off solution would be devised for the particular case, until the project could reach equilibrium again.

I felt there should be a better way.

Looking Past CVS: Comparing the Alternatives

So I got the itch to look at CVS alternatives. I read a fair amount about alternatives, and tried Arch on some personal projects before arriving at darcs. You can read more about why I think distributed source control is the way to go.

I preferred Arch to CVS and found it usable. I simply found that darcs was simpler and more pleasant to use, with a feature set I found sufficient for my needs.