emacsen's journal - Returning to darcs

[Recent Entries][Archive][Friends][User Info]

April 17th, 2008

08:08 am

[Link]

Returning to darcs
After some time spent with git, I've decided to move back to darcs for a majority of my work. Git is indeed a powerful VCS, but the simplicity of the darcs core and tools makes using it more attractive for the work I do.

Git was designed to handle the need of the Linux kernel developers. Those needs included being able to branch thousands of times a day, merge patches back in and handle complex dependency relationships between thousands of developers around the world. In this, git succeeds tremendously.

At the same time, very few projects will ever find themselves in need of this level of complexity. Most projects are run by a handful of people, and for them the key feature is simply being able to branch easily and push and pull changes back between themselves, as well as easily handle patches from the outside. This is where darcs exceeds.

The central core of git is an object database. git uses this database to do binary diffs between code. That is at the core of its ability to handle large datasets and efficiently track file contents across multiple file locations. It is also at the core of git's complexity, since all git operations are calls to this database, which must be kept pristine by careful operations.

The central concept in darcs is a patch. Each commit made to the repository is stored as a delta from the previous state. Patches can be pushed (or pulled) from other repositories, or transmitted through mail or other sources. Patches can also be bundled before distribution, or even include instruction to other repositories to roll back to previous versions.

In this way each patch acts as a revision, and each commit can be cherry picked by other developers. This is on top of darcs's ability to break up individual changes at the patch level. For example if you were to make two distinct changes to your source code before making a commit, both of those changes could be tracked separately, and darcs makes it easy to distinguish the two.

And since each patch is just a patch, while branching is trivial in darcs, a bug which appears in both the production and development versions of code can be addressed with the same patch.

Darcs also makes fixing changes easy. If a patch is committed but then you find a bug related to it, you can simply amend the patch with a fix. This helps keep features managed by binding them to patch bundles. It is possible to do this in git, but you must use --rebase to explicitly disassociate the changes.

Darcs does have a few small drawbacks. It is certainly not as fast as git, but as Linus likes to point out, nothing is. I find darcs to perform better than subversion on the codebases I've used. The authors say that darcs2 has significant performance improvements over the original.

Darcs also uses new nomenclature rather than the RCS/CVS/SVN commands. This is somewhat of a pain, but no more than learning any new tool. Instead of "commit", you'd use "record" or more often, simple "re", and instead of "status", you'd use "wh", short for "whatsnew". This is an annoyance at first but after a few days your mind shifts. If you use an intelligent editor like Emacs or Eclipse, the command details can be completely hidden from you.

I want to end by saying that I'm not a git hater. I much prefer it to some of the other version control systems. I simply believe darcs' simplicity makes it a big win for small projects, and because of that, I'll be switching some of the projects I've done in git back to darcs for the time being. As both darcs and git improve, I suspect we'll see some features of each come into one another, and with automated tools existing to help convert a project from one to the other, I expect to see a diversity of features out of these best-of-breed tools.

Tags: computers

(Leave a comment)