[Top][All Lists]

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

[Gnu-arch-users] DARCS

From: Mirian Crzig Lennox
Subject: [Gnu-arch-users] DARCS
Date: 05 Sep 2003 12:34:50 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Apologies for resurrecting an old conversation, but I finally got
DARCS to run on my system, and I had some (hopefully constructive)

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:

* 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.


reply via email to

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