[darcs-devel] The future maintenance of darcs

[Simon Michael]

David, thanks for your gift to the community, and for sharing your 
thoughts about the future. Darcs has been tremendously useful to me and 
to the Zwiki project, for one.

> One would certainly think so.  But I'd say the experience of the last few
> years suggests that for whatever reason our users aren't interested in
> working on darcs.  I can't say why this is, but it does seem to be how it
> is.  Could we change this with a PR campaign? Nothing has really worked
> yet.  We've gotten a few scattered contributions (for which I'm very
> thankful), but noone has stepped up and worked enough on darcs to be
> seriously considered as a potential maintainer.

I can relate.

I think there is a maintainability problem, perhaps to do with the 
approachability/familiarity of haskell, the complexity of the 
algorithms, cross-platform deployment issues, the build system ? I don't 
know. My feeling is that changes are possible that would tap more of 
that potential developer energy. Enough to reach critical mass and be 
sustainable ? I'm not sure.

> darcs this year just isn't maintainable.  At a minimum, I think we'll need
> to give up on having stable and unstable branches, each with a separate
> maintainer.

That might be a good idea, to focus our energy.

> We also suffer from the fact that darcs uses an inherently less efficient
> and more challenging approach than git/hg/etc.

Is there any hope for reconciling these to get the best of both ? Eg, by 
reviving the git storage back end ? This efficiency/speed issue is 
impactful for darcs' survival, obviously.

> My feeling is that the future of darcs is probably better served at this
> point by discouraging large projects from using it, thus remaining the
> niche where we already are successful.

For the moment, I think that's right. We should make it very clear what 
darcs' niche is (and isn't). Right now I think darcs is good for:

- busy individuals and teams, who don't want to spend a lot of time 
learning rcs intricacies. Darcs' ultra-simple conceptual model (set of 
changes, 1 repo = 1 branch) and well-organized ui wins here.

- small to medium-sized projects with few conflicts

and bad for:

- projects with many conflicts

- projects with very many files or large files

- projects with windows users

What have I missed in these lists ?

I dabbled again with hg, bzr and git recently, and for my relatively 
simple needs, returning to darcs is a breath of fresh air. You're right 
though, something needs to shift if it is to thrive.

Thanks again!
-Simon