Folks,
We've been using darcs for nearly 2 years now, I feel it's time for a
retrospective and to think seriously about whether darcs is still the best
option to continue with. We need to take an informed decision about
whether to switch, that is we need to take the time to evaluate
- What we gain by using darcs relative to other systems
- What problems we encounter using darcs, and whether they would be
addressed by any of the alternatives, or by darcs in the future
- How much effort it is to switch, i.e. we need to list the things
that would have to change
- How much a switch would affect developers and contributors: all of
us have an investment in darcs, so switching costs everyone. Many
of us would still need to use darcs in order to work on other
projects.
- For other VC systems, how would our workflows change: e.g. does the
working/testing repository split work as well with the alternatives?
Let's be honest, if it weren't for certain problems with darcs we wouldn't
be considering a switch at all, so it's worth listing the ones that I
consider to be affecting us:
- conflicts: working with non-trivial branches on darcs is practically
impossible. A fix is in the works, but it's not clear how long it
will be before it is available in a released darcs version.
- speed: many operations are impractical (annotate, darcs changes
<file>), and many operations just take "too long" (i.e. long enough
that you go and do something else rather than wait for it to finish,
which incurs a context-switch cost).
- bugs: we run into darcs bugs that don't fall into the conflict
category on a regular basis.
- user interface issues: e.g. in a conflict there's no way to tell
which two patches are conflicting with each other(!)
- Windows support: is quite flaky still
Generally, darcs doesn't benefit a lot from community support, which is a
shame. There aren't armies of people building tools and fixing bugs, so as
a result darcs has quite a few rough edges, many of which aren't deep, but
some of which are. Personally I wish I had more time to contribute to
darcs, but there are only so many hours in the day. For the GHC project
though, we would be putting ourselves at an unnecessary disadvantage if we
didn't take an objective decision about the best tool for the job (and it
might turn out that darcs is still the best tool, of course...).
What should we consider as alternatives? At least Mercurial and git, I
would think. Any others? I think we should only consider distributed VCs.
I suggest we start a wiki page, where we can fill in the points I made at
the top of this email, so I'll start one shortly. We'd also like to get a
general idea of how people feel about this issue - are you violently
opposed/in favour of switching? Care about any of the points I raised in
particular? Want to advocate one of the alternatives? Please follow up.
---
I should say a little about how *I* feel about darcs. I've grown to love
cherry-picking and one-command merging, when it works. I'd be loathe to
lose the ability to commit/revert a subset of the changes in a tree or file
(I use emacs' darcsum mode). I love the fact that I can unrecord/re-record
patches.
We do need merging to work, though.
I would also really like our repository to be integrated with Trac, but the
speed issues are preventing us from using Trac's darcs integration, and in
general I think many darcs operations are too slow.
I would like it if it were possible to cherry-pick a patch without its
dependencies, resulting in a conflict that needs to be resolved, in a way
that works nicely if you happen to pull the dependencies later too.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
