Hi again, Ganesh Sittampalam <[email protected]> writes:
>> Eventually, yes. For now, it's a work in progress. (In darcs-hs, I have a >> patch to port check/repair to hashedTreeIO and it even works, although it's >> slower than current code by a fair margin.) > > Do you expect to be able to sort that out? > > More generally do you have a target in mind for how complete the transition to > hashed-storage will be before the patches are merged? I think that anything we > merge we should be happy with keeping even if your work stops right there. Well, we need and use virtualTreeIO in a few places. It is reasonably safe and reasonably tested/debugged. I will make things more transparent (by chopping off a read-only TreeIO type and create type classes as appropriate) for this case. For check and repair, I think this change is quite transparent and self-contained as well. It also simplifies the code, although it needs some optimisations. I can sort these out post-mortem and I don't really care that much if we don't merge this part (but it would mean having to retain unsafeDiff for the old check/repair code). For the bigger picture, this may take more time -- writing working copy and pristine state are relatively wide-spread, although I guess replacing uses of applyToWorking and applyToTentativePristine with the hashed-storage versions will flip over most of the code paths. There are two major things to do: - implement tolerant/silent IO in terms of TreeIO, to make applyToWorking safe (this adds a number of error handlers and implements backup-before-overwrite) - flip the switch and make a bunch of heap profiles, so we are reasonably sure of not introducing new leaks I won't promise next week -- and if I don't make it by then, I expect to be only able to finish this off in September. >> This is now done as well. The readIndex function now gives a pair: the Tree >> object, and an action to "update" it. I have documented the new behaviour >> [1] in haddock. It is indeed a little different from the usual Tree objects >> in the sense that it gives you what is in the index file -- >> which may be out of date. It would however be a waste to update all of the >> index every time (although this may be what git does, IIUIC). To make it >> possible to update only a part of the index, you can trim down the index Tree >> and then update the result. It however wouldn't be much of a problem to also >> provide a function that will always give you full, up-to-date index. For >> darcs however, we need (when we say darcs whatsnew subtree) to use the >> partial update functionality. >> >> [1]: >> http://repos.mornfall.net/hashed-storage/dist/doc/html/hashed-storage/Storage-Hashed-Index.html#v%253AreadIndex > > OK, so now what you've got is an API with lots of constraints on how it should > be used and lots of ways to get it wrong. How about an alternate type, > e.g. IndexTree, with its own filter operation, and functions to get at either > the real Tree or both the real Tree and the hash/mtime map (both of which > force > it)? Under the covers IndexTree could just be a Tree with the current > implementation, but at least the API would be safe. So I have thought about this, and what I finally did: - wrapped the Tree that comes from readIndex in a newtype (not exporting its data constructor) - lifted filter into a type class, so it can be used on both usual trees and the index newtype - if we find more operations that are both safe and meaningful on IndexTree, we can lift them into a type class as well The class is a little tricky [1], and I couldn't find a better solution -- if you have one, shoot. This also prompted types like: restrictSubpaths :: (RepoPatch p) => Repository p C(r u t) -> [SubPath] -> IO (forall t m. FilterTree t m => t m -> t m) in darcs-hs, but I am reasonably content about needing this in exchange for the safe API. [1]: http://repos.mornfall.net/hashed-storage/dist/doc/html/hashed-storage/src/Storage-Hashed-Tree.html#FilterTree Yours, Petr. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
