[darcs-devel] merging improvements to 'darcs test'

Ganesh Sittampalam ganesh at earth.li
Thu Jun 13 06:28:47 UTC 2019


Hi,

I have some significant improvements to 'darcs test' (formerly known as
trackdown), that have been languishing on a branch for a while (4 years):

https://hub.darcs.net/ganesh/darcs-testtweaks/changes

(I've since rebased and merged bits of that branch, but it gives the
overall flavour well)

darcs test is essentially the equivalent of git bisect, but with a few
more options for failure finding strategies.

The most important change is to add a concept of 'untestable' states,
equivalent to 'git bisect skip'. This means we can differentiate between
"the thing failed" and unrelated problem like "the build broke".

If there are a lot of untestable states, you end up with a large set of
patches, any of which could contain the failure. Here darcs has a big
advantage over git because of reordering patches: once you have that
large set you can start trying to commute patches out of it to narrow
down the patch that actually caused it. My branch also tries to do that.

I think the final code may need some work and I need to re-remember some
of the details of the changes I made to explain them properly for
review/in comments in the code, so I'll probably work on that gradually.
But there are two major changes I want to make that will affect how I
rebase the patches, so I'm seeking feedback (I guess primarily from Ben,
but also anyone else who is interested) now:

(1)
Firstly I want to introduce an indexed monad to keep track of the
current state of the on-disk testing repository. Otherwise it's pretty
easy to screw that up as I make the logic for trying different
repository states more complicated. There's a draft of this in this patch:

https://hub.darcs.net/ganesh/darcs-testtweaks/patch/ae216b733b2ecb7948419f9d430f7937cb74ecd2

I'd want to check if it makes sense to use a standard library for this
(I think I looked 4 years ago, but perhaps something changed).

(2)
Somewhat related, I also think the core logic of trying repository
states should move out into a separate module. Perhaps
Darcs.Repository.Test.Strategies, but I'd be happy to hear better
suggestions. That would (a) decouple it from the UI (b) mean that the
code needing the indexed monad could be separated from normal IO code.
In my branch I've already abstracted the code over the underlying monad
to make it easier to write unit tests, and that abstraction would form a
nice interface boundary for the new module.

Given we don't have hunk move, I'm thinking of making this change with
'darcs mv Darcs/UI/Commands/Test.hs
Darcs/Repository/Test/Strategies.hs', then recreating
Darcs.UI.Commands.Test and manually moving back the command-related code
that really does belong in UI.

The reasons for doing it this way round is that more of the code will
end up in the new file than the old so this will make annotate easier in
future, and that it'll make rebasing my branch much easier. But I'm
happy not to do that if there are objections.

Cheers,

Ganesh


More information about the darcs-devel mailing list