Strategies for push/merge problem?

[Adrian Buehlmann]

On 16.07.2008 04:03, Sean Russell wrote:
> On Tuesday 15 July 2008 11:12:09 am Adrian Buehlmann wrote:
>>>> "Cheap" commits doesn't mean they are allowed to be brain damaged.
>>> Sure it does. I practice test first design, so I commit tests that
>>> break because the code isn't there yet.
>> Well, there's no need to commit that. But obviously we have different
>> mindsets. You seem to argue that "test first design" implies committing
>> testsuite breaking changes. It doesn't.
>>
>> I wouldn't pull such a patch of yours into any repo I would be
>> responsible for.
>>
>> Why would anyone else need your breaking test *enabled* in the
>> testsuite without the code?
> 
> One of the requirements for proper test-first development is ensuring that the 
> tests actually fail.  I can see a good use case for having that in the 
> history. 

Having a changeset in the official project repo that deliberately breaks the
default global daily (hourly, or whatever) automatic build is plain silly
(assuming the daily build runs the testsuite).

No one would ever want to run the project-wide full nightly build to verify that
a specific unfinished-feature changeset breaks the testsuite.

Such known-to-fail tests would have to be marked as such and be *disabled* in the
default global test suite configuration and only run individually during
development of specific features on specific request or with an explicit option
to run the full testsuite *with* all these tests enabled.

Ensure that all tests which are made to fail are by default disabled in the
testsuite and thus the nightly build.

This should be upheld for every single changeset.

Then you have upheld the invariant that every cset should pass the
testsuite and you can use that invariant when bisecting.