This is the mail archive of the 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).

	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,



[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.
--  <><, Pseudo Engineer, itinerant idiot

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