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