use darcs

I’m now using darcs for most of my personal projects as well as for a couple of libraries I’m using at work. I guess this is “using darcs”. I really like the simplicity of the single directory repository; I like the transparency of the repository format. Some commands still feel unnatural for me but I’m sure that will pass with time. All in all I’m quite pleased to have learned how to use this tool.

I’m now in the process of moving the majority of my personal projects over to darcs. I feel that the main benefit I will get from this is that I will be lowering the barrier to entry for eventual contributors: it’s much easier to bundle up patches and send them to the maintainer of a darcs repository than it is to get commit access and so on for an svn system. It’s also nice to know that people can run their own branches and send patches off based on that whereas with svn you’re stuck either fiddling to maintain a copy of the remote repository or you have to use something like SVK (which of course requires you to install Perl – blecch).

Although I really like a lot of the features that darcs offers, I can’t really see it working out as a tool for me in the long run. This is the first of a pair of entries on the obstacles to my adoption of darcs.

I want to use a version control tool that will work just as well for me at home as it does at work. That means it needs to scale. Not just in terms of its technical capabilities but in terms of the development model that it pre-supposes.

The distributed development model is substantially different from all the preceding forms of centralized repository use. I think it is quite a bit more sophisticated but not always needed (YAGNI).

Indeed I have the feeling that the “natural evolution” of the usage of source control is that we begin in the first age: no control at all. Every change to a file is blindly saved over the previous version.

The next step is copying. At this stage we make a million copies of files. Do you have folders called Backup or Archives? If you do, you may be in the copying stage. This stage is notorious for requiring large amounts of disk space (“delete it? But I might need it! I’ll just make a copy here in my Saved Backups folder.”).

Moving on we come to versioned “in-place” systems like RCS or darcs without networking. All content is placed under version control and the database is either distributed throughout the content (like RCS) or stored centrally but local to the content (like darcs). Many groups of users never reach this stage. Authors and artists and scientists who have worked with computers for over a decade still do not grasp the most basic of versioning concepts (although they are more than happy to create a million copies of each document). In many cases this is because the models provided did not suit their methods of working. The only barrier to using the “in-place” versioning systems are the commands required to explicitly manage the versions since the workflows of the development process remain essentially the same.

In contrast, in the next stage, we move to centralized development models where we work together by synchronizing our work via a central repository. Each of us has our own working copy. This is a very confusing model for a lot of people. The model is further complicated by the fact that it usually will use branching and merging as a first class content management strategy. Previous “in-place” versioning treated branching and merging more like working on a copy of the content than actual parallel development. Now also we begin to seriously take notice of changesets and tags and begin to manage them as part of our strategy.

The final step (or rather, the step beyond which I do not understand source control) is that we each get our own repository and all we do is send the difference between ours and other developers’ around to each other. This is the most complicated of all since developers need to accurately coordinate the exchange of patches because there is no central repository with which they can all synchronize. An organization similar to the Linux kernel development team would be one way of managing that exchange.

Each step along this path of evolution provides greater benefits: finer-grained control over content recovery in the event of disaster, faster recovery, simplified backup routines, etc. But each also incurs a greater cost up-front. I think that the benefits of going full-on distributed will remain less than the costs in my day-to-day work. Thus, if I want to have an SCM tool I use both at home and at work, I’ll need to really work hard to figure out whether the use of darcs is worthwhile!

I’ve just done this recently. Highly recommended! Made my life easier, because I wasn’t using any version control at all before. Now everything’s all locked away in the darcs repository, and “push” and “pull” are really, really natural ways to handle it.

There’s no reason not to try it… just install and start using it. It doesn’t require that do anything special with the files you’re working with, just ‘darcs add’ them, and you’re ready to go. Try it on config files in your home directory so when you mess something up you can see what all has changed, and can try stuff out with the confidence that you can rollback when it doesn’t work.

The simplicity of darcs is amazing.

darcs init

darcs add myfile

darcs record

That’s it.

If your not scared of using the console, definitely give it a try. Pushing and pulling between repositories feels natural and works out very well for branching.

Welcome to a revolution in version control!

Installation on my Mac was straightforward. I have a standard Panther installation with Fink and Xcode. To get darcs compiled, I used the ghc, ghc-dev fink packages. I got some error messages with gmp and readline which was promptly fixed by installing those fink packages. ./configure—prefix=~/root ; make ; make install ; and you’re done.

• Straightforward to install
• Distributed repositories rock for people whose primary machine is a notebook
• Simple repository setup (just “darcs initialize” a directory baby!) makes it easy to version control anything
• Free software GPL-ed
• Written in Haskell and a Theory of Patches, just too geeky!

I’m not the only person with similar thoughts.