[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] DARCS

From: Zack Brown
Subject: Re: [Gnu-arch-users] DARCS
Date: Fri, 5 Sep 2003 16:06:17 -0700
User-agent: Mutt/1.5.4i

On Fri, Sep 05, 2003 at 12:34:50PM -0400, Mirian Crzig Lennox wrote:
> Apologies for resurrecting an old conversation, but I finally got
> DARCS to run on my system, and I had some (hopefully constructive)
> comments;
> I'm not thrilled with DARCS being written in Haskell, but that's
> mostly because I don't program in Haskell, not because I think that
> it's a bad implementation language.  It may be a minor point, but the
> fact that tla is written in fairly vanilla and quite readable C is
> attractive to me.
> On the other hand, there are a couple of things I do like about DARCS:

Darcs is really cool. One thing you don't mention in your post is that
darcs supports arbitrary characters in filenames, which arch doesn't do
(and apparently will not). That's a big deal.

David Roundy (the darcs maintainer) is very nice and doesn't chew people
out and belittle them the way Tom does. That could be considered a

The learning curve for darcs is very gentle. You can basically start using
it right away, without any agony at all.

On the flip side, darcs is a much younger project with a much smaller following
and is still struggling with some fundamental design issues like how to
distribute a repository. Being written in Haskell, darcs will inevitably
have performance issues (although David feels these will be minimal), as
well as trouble recruiting developers. It also seems to have issues with
conflict resolution, that may take awhile to really resolve.

I think darcs could turn into a really nice tool, but not before arch makes
the headlines. Arch has made a really startling amount of progress lately,
or maybe it only seems that way because up till recently it was "just"
a bunch of shell scripts; and that made it hard for many people to take
seriously. Whatever the case, it is looking like arch is now usable, and
about to become very popular. Darcs just isn't at that stage yet.

Be well,

> * You can define multiple matching regexps for different classes of
>   files.  (Currently DARCS has "binary" and "boring" -- boring is akin
>   to Arch's "junk").  As far as I can gather, Arch only allows one
>   regexp each for junk, precious, unrecognised and source.
> * All metadata in DARCS, including tags, is kept in a top-level _darcs
>   directory somewhat like Arch's {arch} directory.  Although this may
>   be somewhat less efficient that putting .arch_ids in every
>   subdirectory, it does have the (not insignificant) benefit that
>   ordinary Unix utilities which traverse source directories do not
>   stumble into metadata directories.
> Additionally, there is a difference of philosophy in DARCS, the appeal
> of which I suspect depends heavily on the development style of the
> user.  Arch requires a bit more maintenance up front when starting or
> importing a project, and this definitely pays off down the line when
> the project and its branches grow complex.  Arch also enforces a rigid
> discipline which helps avoid chaos and mis-coordination.  DARCS on the
> other hand, requires little maintenance up front, and enforces zero
> discipline.  This is appealing for ad-hoc development, where (for
> example) one simply wishes to grab some software package out there,
> and with minimal tweaking make it into a Debian package or *BSD port,
> ending up with a set of diffs to send back upstream and/or make
> available for download.  If the user isn't planning on further
> development on that package beyond getting it to work, the elaborate
> scaffolding in Arch (or even CVS, for that matter) is unnecessary and
> might even get in the way.
> As someone who does quite a bit of both styles of develoment, I found
> the contrast quite intriguing.
> cheers,
> --Mirian
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> GNU arch home page:

Zack Brown

reply via email to

[Prev in Thread] Current Thread [Next in Thread]