[darcs-devel] failing conflict... (and ideas relevant to --set-scripts-executable)

David Roundy droundy at abridgegame.org
Thu Sep 15 05:13:25 PDT 2005


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




More information about the darcs-devel mailing list