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: http://www.siaris.net/index.cgi/index.rss
Feed Description: On programming, problem solving, and communication.
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 http://www.abridgegame.org/repos/darcs
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.
Previous Topic
