- What we gain by using darcs relative to other systems
simplicity. when it works.
- What problems we encounter using darcs, and whether they would be
addressed by any of the alternatives, or by darcs in the future
my main gripe with darcs is its lack of development:
- when i go beyond simple things, i encounter bugs
- the kind of bugs (stack overflow, going to the beginning
of history when operating on the last patch, partial repos
breaking every which way, speed, ..) indicates that the
usual open-source advantages don't apply to darcs: i
cannot be the first to encounter these issues, so they
should have been dealt with long ago
- when i encounter bugs, they are often known, but do not get fixed
- usually, there is a collection of duplicate tickets of the same
bug re-encountered over several months, none fixed
- even when the fix is obvious ("record; unrecord --last=1"
apparently used to work on partial repos, but was broken
in a generalisation attempt), there seems to be no-one
daring to go into darcs internals to do the fixing (David
Roundy mentioned that the code is hard to fix)
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:
..
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.
that, i think is the crucial point: there seems to be only one developer
working on the deep issues, several developers working on clearing
away the easier fixes and feature requests, and none working on core
issues that do not require redefining the theory behind darcs.
perhaps, the ghc project should issue a call for darcs volunteers on the
haskell list, or perhaps, some of the companies using ghc/darcs/haskell
are willing to fund some full-/part-time darcs maintenance. after all,
darcs has become an integral part of the haskell development tool chain.
darcs hacking is likely to be tricky, or else one could try to redirect
some of the shootout and euler problem fans to a collective darcs
hacking effort.. unless there is something very wrong with darcs patch
theory, most of the performance and partial repo bugs should yield to
profiling and code review.. it would have been nice if the last hackathon
had focussed on darcs.
if there is visible progress in darcs development, i would hope that
most of the bugs would disappear (or be replaced with new ones;-)
over a few months. if there is no visible progress in darcs development,
the issues are here to stay. currently, the latter looks more likely:-(
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'm in favour of staying with darcs, if it shows more signs of
being alive and responsive. if resuscitation fails, there
might be no choice. some darcs issues i've encountered:
- partial ghc repo (on windows):
- "record; send; unrecord --last=1" doesn't work
this is a major issue, and working around it with
diff and patch is both fragile and dubious
- annotate doesn't work
- darcs feels unsafe: when something breaks, there's
no guarantee that the repo survives
- complete ghc repo (not much experience with that yet):
- can't "get --complete" ghc or testsuite on windows
- checkpoints are lost with get
- annotate still doesn't work (takes forever, then fails with
stack overflow)
- no nice web interface to darcs repos (because too slow?)
- general
- "darcs-all pull -a" is too slow, and doesn't even use
full bandwith on a slow phone line
- "darcs send" puts everything into an attachment
- "darcs send -o file" needs to be online - why?
- darcs patch contexts are way too big
- inventories/ claim to be .gz files, but are uncompressed
- "darcs changes file --last=1" does not look for the last
change to "file", but for the last global change
- working with recent patches (the most common use
case for me) doesn't seem optimised - unless darcs
is investigating the whole repo history everytime, i don't
know why it is taking so long
- whether by choice or forced by darcs issues, ghc
development does focus around a central main repo;
when i send a patch, i unrecord it locally, and wait for
it to come back after being applied centrally;
perhaps darcs should make use of that, using the main
repo patch order as a reference for the majority of
patches, only weaving in the out-of-order patches
instead of assuming that any patch can be commuted
anywhere in totally unrelated local repo histories?
that might improve command response times,
reduce patch context sizes, and provide reference
points for buildbot reports. without losing the darcs
advantages in the situation in which they matter.
i might remember more once the wiki page is up, i've certainly
seen various darcs tickets created by ghc developers.
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
