[darcs-users] darcs patch: Use index-based diffing in Record. (and 57 more)

[Petr Rockai]

Petr Rockai <me at mornfall.net> writes:
> I am sending the darcs-hs patchbomb, since I just went over the code and
> changes and fixed a few outstanding issues. Now darcs-hs passes the testsuite
> again, and also -- compared to mainline -- fixes issue1488 and issue252.
Ok, on the darcs-hs repo (http://repos.mornfall.net/darcs/darcs-hs) I have now
also purged the Darcs.Gorsvet module. I have also updated
http://wiki.darcs.net/Review/DarcsHS -- we are now down to 8 bullet points.

Out of these, 2, 3 and 8 are mostly trivialities that can be addressed with
just a little bit more time (over the next week, I suppose). I believe 5 is
just a documentation issue, and 6 is partially documentation and partially
thinking on how to make the situation better.

Point 7 is a lot more work, and the question whether it's worth the investment
is a hard one. The problem can definitely be fixed by keeping an extra file
with hashes of the pristine files. This will require a certain amount of
infrastructure work to make a clean interface -- it would basically constitute
a new format in hashed-storage. The result would be a format that is basically
plain and addresses the consistency issues (it'll keep hashes around) for the
most part. It however still breaks down on case-insensitive filesystems (even
though this time, it'll likely lead to unusable repository in all cases, unlike
the existing behaviour of sometimes producing silent corruption). Go
figure... However, I'd like to ask that whatever we decide, we should not block
the merge on this.

However, the situation with 1 and 4 is even more complicated. We are basically
locked up in disagreement with Ganesh about, I believe, basically two things:

(a) Ganesh believes that it's vital to move Storage.Hashed.Darcs (the current
module that holds everything darcs-specific in hashed-storage) into the darcs
darcs repository. I have both practical issues (the hashed-storage testsuite
relies on this code) and theoretical reservations about such move (I think it's
fair to offer this functionality without dragging in libdarcs). A compromise
would have a separate cabal package in the darcs repo, but this does not fix
the testsuite problem. I still prefer to keep the Darcs module in
hashed-storage proper to make life easier for non-darcs users of hashed-storage
(but there currently aren't that many, it's just about lowering the bar...),
but I guess a separate cabal package in the darcs repo would be acceptable as
well (a different compromise would have a separate cabal package outside the
darcs repo, but hosted on darcs.net... hard to weigh pros and cons here).

(b) Ganesh thinks it would be better to overload the Tree type and a number of
associated functions over the Hash type, while I favour the current variant
with a single global Hash data type. We both think that our preferred version
is more readable. I currently can't really think of any serious advantages of
one over the other, as of the current status, with darcs-specific code factored
into a separate module.

Yours,
   Petr.