Fixing rebase rather than avoiding it

Óscar Fuentes ofv at wanadoo.es
Fri Mar 5 02:21:01 GMT 2010


"Stephen J. Turnbull" <stephen at xemacs.org> writes:

>  > How could I teach my script to detect such cases and know that the
>  > revision that breaks the build is not, precisely, the one that
>  > introduced the bug I'm looking for?
>
> It's for Mercurial, but maybe this bisect that I recently did will
> help explain.  The important point is the "if make" in test.sh, which
> uses the return code from make to detect a broken build.

[snip]

> Note that "skip" means that "make" failed, "bad" means that the bug
> was found.

Okay, broken builds are easy to test. Let's go for a more realistic
scenario: a user files a bug report saying that the last update of my
compiler crashes with certain code. He adds a nice test case. So I put
bisect into action looking for the first revision that crashes with that
test case. But it is not so easy, as there are revisions which are
middle points in merged feature branches and crashes on that test case
too, although they are not the source of the bug. Actually, some of
those revisions may crash with any input.

So bisect is rendered unusable here, unless every revision that ends
merged into the master branch have passed a strict QA process. But this
is a serious inconvenience.

Bazaar allows to set a policy that dictates "anything that ends on the
left part of the DAG must pass the strict QA process. the rest is not
required to follow this policy." So you use bisect on the left part of
the DAG and, once located the merge that introduced the bug, proceed to
examinate the merged history and pinpoint the origin (or even try
bisect onto that subset of merged history.)

[snip]

> However, it shows that bisect works fine in the presence of such
> breakage.  (In your case, running a similarly bad set of changes would
> take a whole day, which would be painful.  But it would work,
> eventually.)

I didn't realize that until now. If `bisect' is unlucky, it could end
trying a long series of broken revisions. When that can be expected,
a traditional bug hunting session starts looking attractive.




More information about the bazaar mailing list