Petr Rockai <[email protected]> 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. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
