Merge lp://qastaging/~jeff-licquia/bzr-bisect/yesno into lp://qastaging/bzr-bisect
| Status: | Needs review | ||||
|---|---|---|---|---|---|
| Proposed branch: | lp://qastaging/~jeff-licquia/bzr-bisect/yesno | ||||
| Merge into: | lp://qastaging/bzr-bisect | ||||
| Diff against target: |
69 lines (+37/-2) 2 files modified
cmds.py (+5/-2) tests.py (+32/-0) |
||||
| To merge this branch: | bzr merge lp://qastaging/~jeff-licquia/bzr-bisect/yesno | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Bazaar Developers | Pending | ||
|
Review via email:
|
|||
Description of the change
This branch fixes bug 1051395. The meaning of "yes" and "no" has always been unclear, largely because the original idea for how they should work hasn't matched how it actually works. So, this patch makes things work the way they're described in the docs.
I've put a more detailed explanation in the bug.
Unmerged revisions
- 85. By Jeff Licquia
-
Don't hardcode the association between "yes" and "high revision".
Originally, the intent was for "yes" and "no" to mean whatever the user
wanted it to mean, and figure out at runtime whether that made "yes" or
"no" the high rev. This feature was lost at some point (if it ever
existed) and "yes" was assumed to mean "high rev". This was confusing,
because the docs implied you could make "yes" or "no" mean whatever you
wanted.Now, we figure out from the bisect log which identifier is high, and
stick with that moving forward. Also, there's now a test testing the
"no is high" case.
