On 4/14/16, Warren Young <w...@etr-usa.com> wrote: > > I suppose if you’re working on software with 100% regression test coverage, > such problems would never become buried in the project history: as soon as a > change breaks things, you get told about it by the test harness.
Not so. The better the test suite, the more you need bisect. With a really strong test suite what happens is that the occasional bug that does slip in is probably something extremely subtle and it can go a very long time (years) without being noticed. Finding the origin of the problem becomes very difficult without bisect. Note that bisect can also be used to figure out when a problem was fixed! This happened on SQLite just moments ago. (See http://www.mail-archive.com/sqlite-users%40mailinglists.sqlite.org/msg07964.html for the mailing list post). The OP was concerned about SQLite not making a wise index choice. He sent in the database, and I noticed that my current version of SQLite was making the right choice. I used bisect to figure out exactly which check-in fixed the problem, which also revealed exactly what the problem was without me having to spend time debugging it. > > The ability to bisect is one of the strongest arguments in favor of version > control. +1 -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
