meaning/usage of "yes" and "no" are unclear

Originally, the meaning of "yes" and "no" was intended to be dependent on how you used it. If you started out with "yes" meaning the same as git's "good", it would honor that; if you started with "no" meaning "good", it would do that too.

The reason: I didn't like the "good" vs. "bad" naming in git. If you were trying to find a fix or new feature, say, instead of a regression, then you'd be saying the feature was bad. My thought was: create a question that can be answered "yes" or "no", and answer it for each revision. As long as the question was the same, it should work.

Unfortunately, I never wrote a test for this, and the functionality bit-rotted (if it ever worked to begin with).

I've posted a branch which fixes this, as well as a functional test for the feature. With this branch, this:

bzr bisect start
bzr bisect yes
bzr bisect no -r -3

and:

bzr bisect start
bzr bisect no
bzr bisect yes -r -3

should be exactly equivalent.

I'll propose my branch for merging. Assuming this works, does it resolve the confusion you had?

Not exactly :-(. I implemented bug 683822 yesterday in lp:~naesten/bzr-bisect/683822-bisect-start-range-argument , and now when I try to use the feature for a real bisection I discover that it uses the opposite convention from "bisect run"!

I think it would be much simpler to keep straight if we just called them "bad" and "good", and never mind if the meanings sometimes have to be reversed to get the desired results...

Did you use my fix when testing your new feature?

Well, it seems to have somehow interacted with my test changes to cause this:

FAIL: bzrlib.plugins.bisect.tests.BisectFuncTests.testWorkflow

but "bzr bisect run" still seems to be treating success and failure the opposite of the way it should...

Hmm, well, I decided to switch the polarity of "-r" instead of trying to get the return values -> status mapping changed, since "start -r"/"run -r" are new and "run" isn't, so changing the polarity for "-r" isn't going to break compatibility. (Obviously, this requires your lp:~jeff-licquia/bzr-bisect/yesno changes. Well, probably, anyway.)

Oh, but the docs still probably need to make it explicit that "yes" and "no" are nearly interchangeable, rather than being vague about it like they currently are?