[darcs-users] Delta Debugging

[Andrew Pimlott]

On Mon, May 24, 2004 at 08:10:02AM -0400, David Roundy wrote:
> One question is whether to use a clean copy for each test.  Trackdown
> doesn't do this currently, which is nice because it means you only have to
> recompile files that are modified from one version to the next, but could
> lead to "interesting" histeresis effects if there are bugs in the build
                        ^^^^^^^^^^^^^^^^^^
Warning!  Physisict playing programmer!

> system.

Obviously offering both would be ideal, but practically people will be
less likely to use this if it takes all night and day, so I would
default to applying patches without cleaning up.  This will encourage
people to fix their build systems, which they should do anyway.

> Another thought is that perhaps we could also add an "--auto-depends"
> feature to record, which would use some sort of clever algorithm (related
> to delta-debugging, perhaps?) to run a number of tests to see which patches
> are required by the being-recorded patch in order to pass the tests.

Yes, yes!  This would make it much more feasible to cherry-pick patches,
because you can have reasonably confidence you'll get all the
depended-upon patches with it.  Although since any automated dependency
detection will be imperfect, there should be a way for a person to add
or remove these relationships manually.

> I imagine implementing something like
> 
> latest_working_version :: FilePath -> (IO ()) -> (IO Bool) -> IO PatchSet
> 
> where the first argument is the location of a repository (a PatchSet could
> be given instead, but we might want to throw away and reread the patches to
> save memory), the second argument is an initialization function, and the
> third is the actual test.

I think the initialization function should be IO Bool--that tells you
whether (eg) your compile succeeded, mostly solving the problem of
distinguishing between the target bug and compile errors.  Also,
hopefully this is obvious, but the third argument should be
user-specifiable, because you often want to run a small test case, not
the entire test suite.

Andrew