[Haskell-cafe] Re: poll: how can we help you contribute to darcs?

[Austin Seipp]

Excerpts from Andrew Coppin's message of Sun Aug 03 04:35:32 -0500 2008:
> Correct me if I'm wrong, but... I was under the impression that Darcs is 
> a revision control system. It controls revisions.
> 
> Well Darcs already does that. So... what's to develop? It's not like 
> it's slow or buggy. I can't actually think of any features it doesn't 
> have that I want. So... what now?
> 
> In case that sounds really negative and critical, let me phrase it 
> another way: Given that Darcs is more or less perfect now, what's to add?

At this point I feel it is an issue of what can be fixed rather than
what can be added.

The current issues with darcs right now I feel are:

 * Predictability. There is no such thing with darcs. If I try to get
 copies of the base libraries up to date in the latest GHC-head
 (via a ./darcs-all pull -a,) it might pull all the libraries. It
 might not. It might randomly stop at identifying the repository
 format of 'base/array.' It might get all the way to 'base/unix' and
 begin pulling patches before it stops. In either case, darcs never
 quits, I'm never sure of what state it is in during the pull and
 frankly I just don't know what's going on sometimes.

 * Usability is dodgy under high load. To date, I think GHC is the
 best candidate for qualifying as 'high load,' but even then I'm not
 sure if the comparison is quite as fair if GHC is still using an
 old-fashioned darcs format (i.e. darcs1-style repo.) Regardless I am
 still skeptical at this point of darcs ability to handle high load.

 * Random quirks, e.g. some file edits may unknowingly introduce an
 explicit dependency on patches, meanining while two patches A and B
 are unrelated in all forms of the word, it will still mark 'A' as
 dependent on 'B'. So you've basically lost the ability to unrecord
 flexibly, since unrecord is going to skip the patches that are marked
 as dependent on something else, when they really are not.

Quite honestly I think darcs 2 is a fine release and a very good
improvement; it fixed a lot of the older nasty quirks
(exponential-time merge bug in particular) and any project considering
darcs should use the new format immediately. I think for medium to
small sized projects it is great. It will continue to fit those
projects very well, but when push comes to shove, darcs won't cut it,
I feel.

To answer the question and be honest about it: I would work on darcs
if I was getting paid.

Darcs lost I think because of its internals, because it simply was not
feasible for people to get involved and make core improvements. You
basically were either David or you weren't. Other VCS's generally
speaking have a lot more simple foundation: git only has only 4 base
objects that you encounter every day in your workflow. These are the
primitives of all operations in git, and everything else is built on
top of them. Because of it, anybody with some experience in using git
can probably get reasonably comfortable with the source code in a
non-crazy amount of time. There is a lower barrier of entry to the
source code, ideas and development process. The simpler design simply
facilitates contributions where it matters, IMO.

While I don't want to sound so unsupportive of the excellent work
everybody involved in darcs has contributed, that is currently the way
I see darcs and unless I was getting paid I would not be compelled to
work on the source code as I have already moved to another system
(git.)

I think darcs made a landmark is usability for a DVCS, and I also
think the way in which patches are managed with darcs is very
nice. However, I've found git's approach sufficiently simple (to the
point where my limited brain can comprehend it) and cherry-picking is
a common point among version control systems these days (git add -i.)
So I've found home elsewhere.

Austin