On Tue, Sep 13, 2005 at 04:43:50PM +0200, Tommy Pettersson wrote: > I just pulled the latest patches from darcs stable and run > a slowtest that failed. I have attached the output.
Alas, this is just a symptom of our poor test suite. In particular, we don't handle binary patches. The two patches that are being merged in this case cannot exist in parallel. The trouble is that it's hard to see this. It's actually easy for a *human* to see, but PatchCheck stores the state of its "knowledge about the tree to which these patches could be applied" in a format that doesn't mesh well with binary patches (and was designed for hunk patches). It also fails for replace patches. One related issue that I was just reminded of is that our latest apply sacrifices redundancy for speed, in that it doesn't check whether the old version of a file agrees with the patch contents. It might be nice to add some sort of a "carefully" option to apply. We would then always carefully apply patches when repairing or checking the repository, and might have it as an option for pull/apply/get. We might work this through the same interface as we handle the --set-scripts-executable, if we changed apply to apply :: WriteableDirectory m => [DarcsFlag] -> Patch -> m () The idiom of passing [DarcsFlag] around is a bit weird, but is often useful. I'm imagining a pair of (mutually exclusive) options, something like --careful and --fast, with the latter normally being the default, but the former being the default for check etc. And the latter might be useful for a new "PatchCheckMonad", which might allow PatchCheck to be written as a WriteableDirectory... although it's not easy to see how we'd manage this. -- David Roundy http://www.darcs.net _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
