On Thu, 6 Aug 2009, Petr Rockai wrote:
[treeDiff vs unsafeDiff]
I have read the code again and I take that back. There are just four
problematic cases that need checking:
- empty -> text with trailing newline
- empty -> text without trailing newline
- text with trailing newline -> empty
- text without trailing newline -> empty
I have thrown together a small testcase that checks these four cases
explicitly. (I must say that darcs creates quite curious hunk patches
for the no-newline cases...) It is available in
tests/trailing-newlines.sh in current darcs-hs.
OK, cool. I'll try to audit the code to confirm your assessment too.
Also, darcs check should check the index (and darcs repair fix it).
Hm, it is always safe to rm _darcs/index, so repair could just do that.
As for check, it should be easy to implement, I'll do that in a bit (all
it needs to do is read the index and pristine, check that the file lists
match and then recompute the hashes from actual file contents of working
files... did I miss something?).
Sounds right to me.
Aha. Yes, virtualTreeIO is an exception in this case. I'll work on the
Monad a little more, probably over the weekend. (I do use virtualTreeIO
in place of apply_to_slurpy in darcs-hs... or more precisely, we use it
to implement applyToTreei -- that's basically one of the intended
use-cases. The other is to do read-only things -- it may be however
better to have a read-only monad for that use-case -- basically a
counterpart to ReadableDirectory.)
That sounds like a good idea.
Well, hashedTreeIO is currently not used. Well, it is used by darcs
check/repair in darcs-hs, which does its own cleanup. This is however
something that will need addressing.
OK, I'm now rather lost about what is needed for what. I'd have
expected hashedTreeIO to be needed for everything that touches pristine
in a hashed repo. Is this just a work in progress?
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.
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.
Cheers,
Ganesh
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
