Hi Jakub, On Mon, 2015-08-24 at 10:17 +0200, Jakub Jelinek wrote: > > Jakub: How about using git bisect instead, and identify the compiler > > binaries with the git commit sha1? > > That is really not useful. While you speed it bisection somewhat by avoiding > network traffic and communication with a server, there is still significant > time spent on actually building the compiler.
In LibreOffice land (thanks to Bjoern Michaelsen) we use and publish binary bisection repositories (bibsect). It takes of the order of an hour+ on some cutting edge hardware to build each of our binaries - for most people longer - so we archive our live, runnable commit as you do - but we check those images into a new git repository. Each of those is checked in with a commit message that points to the source hash. > The way I use bisection is that either I have for every 50-200 > commits a cc1/cc1plus/f951 compiler already built (that is on my ws) or for > every non-library commit to the branch that could affect the compiler (no > testsuite changes etc.). So in our model, those would all go in git and get packed with an aggressive git gc. We publish these repositories too[1] - with thousands of binaries built inside them so non-technical QA guys can download and locate the right developer to blame for their pet regression long after the date). Interestingly mostly non-technical QA guys have done this for several hundred regressions in the last few years. > And for those really identifying them by sha1 > hashes is significantly worse than using monotonically increasing small > number, sha1 hashes are impossible to remember, and you don't know what is > earlier and what is later from just looking at it. That's of course true; the hashes are a pain - but bisecting in the binary repository is easy enough I think - and there is IIRC some degree of built-in tooling for running scripts/tests on each version to automate that (I'm sure you have something like that already). https://wiki.documentfoundation.org/QA/Bibisect#Introduction has some fluff on our approach. Of course, aside from that git takes quite some learning to love ;-) but as/when you're there you wonder how you lived through RCS, CVS, SVN, etc. HTH, Michael. [1] - this of course involves some horrors of different Linux and ABI issues and so on that (I hope) gcc would be less prone to problems with. -- michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot