David,
Thanks for that summary!
Given that a first version of the New Darcs seems to be just around
the corner, I am very much in favour of giving that a shot before
moving over to a new vcs. Switching to a new vcs is a significant
investment, especially for those who haven't used that new vcs
seriously before. Maybe we should just invest that effort into
helping David improve his code instead.
Last, but not least, we have made a lot of noise about what we want to
see improved in darcs. Now, it seems David has invested much time to
address these issues. So, I think we owe him at least to seriously
try his new code before moving somewhere else.
Manuel
David Roundy:
Hi all,
Don just pointed out this discussion, and suggested I drop by with a
status
update.
First off, you're right that we're very short on developers for darcs.
None of our experienced developers have much time just for darcs
development just now (with the exception of myself), and we've had a
distinct drop in the number of new developers joining the project.
I'm not
quite sure why that is, but I think in part it is because darcs is
Good
Enough for most developers. It's almost exclusively large projects
(like
ghc) that run into the major infelicities of darcs, and most
developers who
work on large projects don't have much time to contribute to darcs,
while
haskellers who work on small projects are happy with darcs as it is.
I've been working on the conflicts problem (as some of you are aware)
pretty much exclusively (apart from time spent with my Physics PhD
student)
for the past few months (since August). As of last week, I've got an
implementation of the internals that passes all tests I've been able
to
throw at it, and I am now in the process of adjusting the high-level
code
to use the new patch semantics. If I didn't have a grant proposal
due next
Monday, I'd expect to have a working version of darcs in the next
week,
it's moving that fast. It helps that the new code implements
semantics are
very similar to the existing semantics.
Darcs 2 will use the new "hashed inventory" repository format that
some of
you are familiar with. The format cleans up the concept of a
"partial"
repository basically by allowing lazy downloading of patches as
needed. I
believe this will address most of the problems ghc folks have
reported with
--partial repositories, which is why I developed this format. It
also has
advantages in terms of atomicity and in that it enables easy signing
of
repositories to verify the complete contents.
I suspect there will be major performance regressions, however, with
the
new code, because much of it was written with scaling and
correctness in
mind, but without special care to ensure laziness to keep down
memory use.
So hopefully once the test version is out, we can get some serious
performance testing. I plan on devoting what time I can to fixing
performance (and correctness) issues over the next semester,
although I'll
also need to devote more time to Physics than I have this semester.
I do plan on writing a paper on darcs' semantics and submitting it
to POPL.
Oh yes, and also in the plans is a couple of new formats for darcs
patches,
particularly hunk patches, which should greatly improve parsing and
file-writing times as well as memory consumption. Basically, the
idea is
to store the new and old version as contiguous blocks of bytes
(without the
'+' and '-' at the beginning of each line), so that we can skip
right over
hunk patches when parsing.
I'm sure that I haven't addressed all of the concerns that have been
expressed here, but hopefully you've got a somewhat clearer idea as to
what's been going on in darcs-land. To reiterate, we *are* very
short of
developers. Most of us (former and current darcs maintainers) seem
to in
academic jobs which don't leave us much time for hobbies.
Contributions to
the development effort would be very much appreciated!
Incidentally, at this point, darcs development is also provides an
opportunity to play with GADTs and existential type witnesses, as
we've
gotten that going in the code. I expect I'll end up writing a
separate
paper on that subject, since it's a neat set of tricks to statically
eliminate rather a large class of bugs.
--
David Roundy
Department of Physics
Oregon State University
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
