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

[Samuel Bronson]

The only real clue about what "yes" and "no" mean comes from this part of the help:

  bzr bisect run <script>
      Bisect automatically using <script> to determine 'yes' or 'no'.
      <script> should exit with:
         0 for yes
         125 for unknown (like build failed so we could not test)
         anything else for no

and *that* is mostly by analogy with git.

This leads me to believe that "yes" is for revisions before the change sought, and "no" for those after it; in git's terminology, "yes" is "good" and "no" is "bad.

Is that true, or at least consistent? If not, well, that's downright misleading. Anyway, it ought to be clarified, explicitly and/or through examples.

[Jeff Licquia (jeff-licquia)]

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?

[Samuel Bronson (naesten)]

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...

[Jeff Licquia (jeff-licquia)]

Did you use my fix when testing your new feature?

[Samuel Bronson (naesten)]

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...

[Samuel Bronson (naesten)]

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.)

[Samuel Bronson (naesten)]

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?