Then @K.F or @Mkilbride -
Please use the binary search method to determine which revision broke it so we can make a report.
Copied from a post by Bositman:
So with your awesome testing skills you've found a bug, yay! (not so hard now is it?
)
But in order to fix it, it helps tremendously to find out which code commit caused it (not always possible, but we will assume so here).
To do this, we will use the binary search method, which guarantees us that we will find the code commit we are looking for in
5 tries maximum.
How does it work?
Let's say for example that we currently are at revision 500 of github (we will use build bot revisions since github hashes don't help much in this case) and the bug is there.
Our range is revision 1 to revision 500 and we know that rev 500 has the issue.
We start by testing the revision between our range, exactly in the middle, so revision 250.
If the issue occurs in rev 250, it means the bug is somewhere between 1 - 250, else it's between 250 - 499
a) 1- 250 we repeat the process so we test rev 125
b) 250 -500 we repeat the process so we test rev 375 ( 250+500 / 2 )
and so on and so forth until we end up with a revision that doesn't have the bug and the exact next revision has the bug.
The revision we are looking for is the last one that didn't have the bug so both of the above statements must be true.
a)Revision X doesn't have the bug
b)Revision X+1 (the exact next one) has it.
Here is a visual example of the algorithm, while searching for number 76.
Our range is 2 to 94 and we start our search from the middle, 47.
Since 76 is larger, we then search from 51 to 94 and start from the middle, 77
Since 76 is smaller, we then search from 51 to 76 and start from the middle, 64.
Since 76 is larger, we then search from 76 to 76 (
) Oh wait we found it!