These are Simon Marlow's notes on areas that darcs needs to improve on to be
useful for GHC:
I promised to put together our reasoning on why we don't think moving to
darcs2 would help enough. Here's a summary:
- using the darcs2 format may well fix the exponential-time merge problem,
but the UI for merging conflicts is still lacking in many important ways
in darcs:
* The conflict markers are not annotated with the patch that they came
from, and the ordering of patches in conflict markers is
non-deterministic (when I asked about this problem, I was told it was
hard to fix).
* The 'darcs changes' output only shows one of the patches that is
conflicting, you have to guess at the other one(s). Also, it doesn't
show which patches are conflict resolutions.
- Performance. darcs2 regressed in performance for many operations we
commonly use. I've submitted some measurements for some things, but
it's pretty easy to find your own test cases: things like "darcs add",
"darcs whatsnew", "darcs unrecord" are all slower than darcs 1. When
simple operations take multiple seconds to complete, it really slows
down your workflow.
- I still can't use 'darcs annotate' because it's too slow. Also, we
can't browse the GHC repository on the web because the web interface
wants to do 'darcs changes <file>', and that takes minutes. It's
possible with caching, but you still have to regenerate the cache
after a change.
- why can I do a complete git clone of a remote GHC repo in a few minutes,
but it takes hours to do a complete 'darcs get'?
- Bugs. Many bugs have been fixed in darcs2, which is great, but we
did already encounter one (hard to reproduce) bug on Windows,
when trying to get an up-to-date repo. Perhaps bugs will be less of
an issue in the future, but we have had painful experiences
particularly on Windows and I know the darcs developers are still
not actively testing on Windows.
Attachments
|
