The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
Looking at darcs

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Andrew Johnson

Posts: 39
Nickname: jandrew
Registered: Mar, 2004

Simple things ...
Looking at darcs Posted: Jan 24, 2005 2:41 PM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Andrew Johnson.
Original Post: Looking at darcs
Feed Title: Simple things ...
Feed URL:
Feed Description: On programming, problem solving, and communication.
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Andrew Johnson
Latest Posts From Simple things ...

byline: Andrew L Johnson

I like simple, so when I heard that darcs is a simple (but rich) distributed version control system, I had to take a look.

darcs is a relatively new entry on the version control landscape, officially announced in April of 2003 it passed the 1.0.0 milestone in November of 2004 and now sits at 1.0.1. It is written in Haskell, and you’ll need the Glasgow Haskell Compiler (GHC) to build it from source, but there are binaries available for many platforms. The linux static binary worked out of the box.

What makes darcs different is that you don’t check out working directories, but rather fully functional repositories — essentially branches — without any of the fuss or administrative overhead of setting up local branches / repositories that some other version control systems require.

So, if I do

  darcs get

I wind up with a full repository of the darcs sources — in which I can make changes, record, unrecord, revert, pull down new patches, or create patches to apply back to the "main" repository (using darcs push if I had write access to the that repository, or darcs send to send via email where they might either be manually or automatically applied). Of course, I could share my patches directly with another developer equally as easily if we both working on some fix or feature.

(Note: darcs get —partial … is recommended if you don’t really need the entire patch history of the project — it will just fetch the patches since the last ‘tagged’ version and build your repository based on that. Currently with darcs, that’s the difference between getting some 2500+ patches or just getting and applying few hundred).

This tutorial illustrates how easy using darcs is, and the manual itself is a well written guide and reference (which also discusses the underlying Theory of patches of darcs). So I won’t duplicate that material here.

I will mention one experience I had with darcs itself. I decided I’d rather build darcs from source rather than rely on a binary, so I downloaded a binary install of GHC, used my binary of darcs to get the darcs repository, and built my own version. Unfortunately, the GHC I installed was broken on my system, and any system() calls failed (and darcs uses system() calls in a few places such as bringing up your editor to write long log messages, or for running automated test commands). My first attempt to build my own GHC from source also failed.

So I dove into the darcs sources (without ever having looked at Haskell code before) and was able to come up with a workaround patch that replaced any system() calls in darcs with an execvp based alternative — this solved my immediate problem, and everything worked fine.

Now I wouldn’t expect a patch for my isolated case to be incorporated into darcs, especially since my real problem was the GHC compiler and not darcs. But then, I do have my own fully functioning branch right here which I can still keep up to date by pulling down new patches from the main repository (resolving any conflicts if they arise). In fact, a couple of new patches were added to the repository, and I just did:

  darcs pull

within my own repository and it interactively asked me about applying each patch in turn (I could have had it not ask), applied them, and I recompiled — no problem, no headache.

That was quite nice to know. Fortunately, I did manage to get a working version of GHC compiled on my machine (with a little baby-sitting during the compile), thereby solving my real problem and allowing me to unpull my specialized patch from my repository. Cool.

In reworking the code section of this site, I decided to make the few small Ruby and Perl projects currently there available as darcs repositories (along with tarballs).

A couple of other darcs features:

  • atomic commits
  • file and directory moves handled
  • token-replace patches
  • symmetric repositories (full darcs power in any copy)

But the number one feature I like is that it is damn easy to use without sacrificing power.

However, it’s not all roses and there are a couple of caveats:

  • a repository costs 2 source-trees plus in disk-space (at the present time — though hard-linking is done when possible between copies on local filesystems, and besides, diskspace is cheap)
  • Large source trees with many changes can be slow to fetch, and require lots of memory (but memory is cheap too).
  • Really complex merges may take a long time (exponential algorithm).

Work is being done to address the above issues, and in the meantime, darcs is cetainly capable of handling small to medium projects (say perhaps, into the 10’s of thousands of LOS[1] range). Darcs is self-hosting and runs some 28,000+ LOS.



  [1] LOS = Lines Of Stuff

Read: Looking at darcs

Topic: ‘That application is so stupid’ Previous Topic   Next Topic Topic: Beyond the 10,000th gem install of Rails

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use