This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Moving to git - bibisect ...


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.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]