[darcs-users] Re: testing patches that change the test pref

Mark Stosberg mark at summersault.com
Wed Mar 23 17:00:17 UTC 2005


On 2005-03-23, Phil Frost <indigo at bitglue.com> wrote:
> On Wed, Mar 23, 2005 at 03:46:04AM +0000, Mark Stosberg wrote:
>> On 2005-03-23, Phil Frost <indigo at bitglue.com> wrote:
>> >
>> > I am wondering what darcs does when testing patches which change the test pref.
>> > I have such a patch here, and it seems to be failing because it is using the
>> > test command prior to applying the patch. If I run 'darcs check --test' in a
>> > repo with the patch already applied it passes.
>> >
>> > This in not the behaviour I'd expect, because it makes it impossible for many
>> > patches that change the test framework to pass the tests. Is this a bug or a
>> > feature?
>> 
>> The basic issue here is that you had a testing preference that was broken. 
>> So of course it's always going to fail. 
>> 
>> Just use "--no-test" to record the patch that fixes it and move on.  
>> 
>> I think to change the current behavior would involve too much guessing
>> about what is known to be broken and working about your repo.
>> 
>>     Mark
>
> No, the old testing preference works. The new testing preference works
> too, with the patch that changes it applied. In other words, I have
> patch P which changes my test program, and the test pref. The set of all
> patches except P passes the tests. The set of all patches, including P,
> passes. But all patches, including P, but not including the changed test
> pref included in P does not pass.
>
> I would expect that patches with a setpref test would use the new test
> command when testing them. Because tests are atomic, testing the changes
> without the change in the test pref is invalid, and in this case,
> broken.

Ok, now that makes it sound like a bug in darcs. What do people think
about this solution:

 Have darcs immediately record any setpref, so it becomes it own
 transaction, like 'darcs tag' works? When this is done, the   
 test suite should not be run.

Then your process could be:
 - run atomic darcs setpref 
 - commit patch that passes with new setpref. 

Until then, I guess the workaround is to put your setpref and other
other updates into two different patches, and use the --no-test option
appropriately in the transition.

    Mark





More information about the darcs-users mailing list