[cdt-dev] bisecting regression ranges

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

Hi,

Sometimes, when investigating a regression, debugging the problem directly (without knowing where to look for it) can be quite difficult. In these cases, it really helps to identify which commit caused the regression.

Given a "known good" revision (a previous release which does not suffer from the regression) and a "known bad" revision (e.g. head of master branch which suffers from the regression), the commit that caused the regression can be identified by testing O(log N) revisions (where N is the number of commits between "known good" and "known bad"), using binary search.

For another project that I work on, there is an archive of builds for every revision, and a tool that guides you in performing this process by downloading relevant revisions in turn and running them, and asking you if the current one exhibits the problem.

Is there some similar way to bisect a regression range for CDT? I tried using "git bisect", but I had trouble building older revisions, due to mismatches between CDT and Platform code. For example, for the revision from which 8.8 was branched (which is the "known good" revision for a particular regression I'm investigating), I was unable to build that using any of the available target platforms.

It would be particularly hepful if there were an archive of builds - if not for every revision, then at least for every nightly build. Is there such an archive somewhere?

Thanks,
Nate