Books of Note

Practical Common
LispThe best intro to start your journey. Excellent coverage of CLOS.

ANSI Common
LispAnother great starting point with a different focus.

Paradigms of Artificial Intelligence
ProgrammingA superb set of Lisp examples. Not just for the AI crowd.

Friday, January 28, 2005

Moving to the darcs side 

A while ago, I went and asked the question about why Gnu Arch was so popular among Lispers. I got some replies from people that suggested that Arch was clearly superior to CVS/Subversion in a number of ways, and so I decided to give it a try. After a few months of relatively light use, here's my report. I won't rehash a lot of the general Arch vs. revision-control-X sort of stuff. You can find a lot of that on the Arch Wiki website and the websites of all the revision-control-X's out there. Note that these are my observations. If you're using Arch successfully and think it's the tip-top, fine; carry on.

On the pros side:

On the cons side:

I spent some time reading comp.version-control.arch.user last night to get a feel of how other people are using the system. It turns out that many of these problems are known, though some not recognized (internalized?) as problems. I saw a lot of Arch defenders dismissing things simply as "user interface problems," as if we were simply talking about a pixel being out of place somewhere. Frankly, whenever I see that, I get scared. What is the purpose of a program if not to interface to a user such that the user can accomplish tasks with it. If the program makes it so confusing that users can't get done what they need to, quickly and easily, then what good is it? Arch strikes me as a powerful program that has evolved without a lot of UI direction.

Tom Lord, Arch's creator, is probably a brilliant guy, but he needs to take a class on user interface design. No, I'm not talking about GUIs with pretty colors and dialog boxes, but just your basic "users need a simple mental model of the system and if you don't provide that, everything will be confusing and complex, even when it doesn't need to be" sort of thing.

Others will say that I'm confusing complexity for power. "When a tool is powerful," they'll say, "it's bound to be complex." And Arch is certainly powerful. Well, there is a case to be made that tools that do a lot of things naturally end up with a lot of commands. Yes, that's true. But those commands can be organized in simple ways. And simple processes can be given simple commands to execute them. As Einstein is reported to have said, "Everything should be made as simple as possible, but no simpler." In this case, I believe Arch could be much more simple.

So, when I first asked my question about Arch, one kind reader suggested I check out darcs. After getting irritated at Arch last night, I did. In short, darcs seems amazingly streamlined and intuitive when compared to Arch, but provides basically all the same advantages of distributed version control. After quickly skimming the manual, I was able to set up repositories, create patches, branch, and merge. The command set is small and rationally organized. The basic processes take only a couple of commands to execute. There are no funky names of repositories, etc. Further, darcs seems to work on Windows quite well, which has been a limitation of Arch before this. While I use Linux mostly, there are times that I have to deal with Windows and it's nice to know that I could use the same systems on both environments.

In reading comp.version-control.darcs.user, there are a few limitations to darcs currently. Darcs is at version 1.0.1 as I write this, with a 1.0.2 imminent. Arch has had more time than darcs to become feature rich and optimized. Some current limitations of darcs seem to be:

As a result of all this, I decided to "go over to the darcs side" for a while and give it a try. I'll let you know what I find out for my own personal projects.


I had the same difficulties with arch, so I switched to darcs a couple weeks ago.

I haven't used it too heavily, but I do like it a lot better. My main criticism is that patches in darcs don't seem to be numbered or designated by anything other then the patch name you supply. This seems like it could be problematic if (accidentially) you name two patches the same.


As a Lisper, haver you tried Meta-CVS? I am using it since a few days ago, and I found it quite convenient for my humble needs.

Kind regards,


darcs actually does generate a unique identifier for each patch; these identifiers are used for the patch file names which you can see in a repository's _darcs\patches directory.

You can use the "--match 'hash <patch id>'" option when a patch name is not sufficiently unique.

I had exactly the same reaction you did to Arch. There is likely some good thinking about version control that went into the program, but I won't be likely to find out because the user interface is just *so* bad. It gives me some hope that some people have recognized this, like the Bazaar folks (, but for now I've given up on Arch.

I ended up switching to Monotone, which I've been really impressed with. The current implementation is a bit on the immature side, but the developers are rapidly ironing out the remaining bugs. Strong integrated crypto, a simple, powerful approach to version control, and a nice UI just make it a pleasure to use. In that past Monotone hasn't supported per-file commands (like the ability to "diff" or "commit" a single file, not the whole tree), but that has recently been added in the development sources (and should be in 0.17). In short, check out MT!

I have switched to darcs too some months ago. :-)

Now if darcs just had a kick-ass Emacs interface like Xtla...

--Christian Neukirchen

I've seen darcs some time ago but decided to give it a try aftrer reading your article (and after I've found out it's prepackaged on gentoo :)). Generally, I find it much easier than arch and more powerfull than CVS (but what isn't these days?).

One thing I don't like is that a server needs darcs installed. In this regards it's more like CVS than arch, since the latter can work on a very dumb server. E.g. I've got a machine with a FTP access, and that's enough for arch but not for darcs.

Ok, I know I can mount the ftp directory on the local filesystem and it'll probably work, but that's beside the point.


You only need darcs on the server in order to push patches; you can pull from a dumb server quite fine.

A solution that some people use is to keep a master copy of the repository on their private machine and use rsync (or ssh, or ftp, or whatever) to propagate changes to the server.

nice write up.

Post a Comment

Links to this post:

Create a Link

This page is powered by Blogger. Isn't yours?