(original) (raw)
On 6/8/06, Tim Peters <tim.peters@gmail.com> wrote:
...
\[Tim\]
>> What revision was your laptop at before the update? It could help a
>> lot to know the earliest revision at which this fails.
\[Brett\]
> No clue. I had not updated my local version in quite some time since most
> of my dev as of late has been at work.
A good clue is to look at the "Revsion: NNNNN" line from "svn info"
output executed from the root of your checkout. Or if you have the
Python executable handy:
>>> import sys
>>> sys.subversion
('CPython', 'trunk', '46762')
No, I'm not making that up!
Oh, I believe you. Issue is that I did a svn update when I got home today. I have another checkout that I never modify (to use as a reference checkout) that I have not updated since rev. 43738 and it passes the tests. That sure helps narrow it down, doesn't it. =) A quick check of rev. 46750 has the test passing as well.
>> ...
>> Doing a binary search under SVN should be very easy, given that
>> a revision number identifies the entire state of the repository.
> That would be handy. Question is do we just want a progressive backtrack or
> an actual binary search that goes back a set number of revisions and then
> begins to creep back up in rev. numbers when it realizes it has gone back
> too far.
What we really want to do is solve the problem.
Of course.
If we're going to tie
up my machine doing it, I want as few builds as theoretically
possible. If we're going to tie up your machine, it's fine by me if
it goes back one checkin at a time until 1991 :-)
=) On my slow machine, it might be another 15 years before we get to current on HEAD.