Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Tuesday, October 09, 2012

rewriting history means rerunning tests - for all versions in new history?

Something that annoys me about rewriting history in a version control system like Git or Hg, e.g. rebase, is that strictly speaking one should rerun all tests on all of the new versions.

E.g. if you had

        trunk:     A->B->C

and made your edits


        trunk:     A->B->C->X->Y->Z

and eventually wanted to merge into history from elsewhere

        trunk:     A->B->C->D->E

by rebasing

        trunk:     A->B->C->D->E->X'->Y'->Z'

then you *might* want to rerun tests on all of X', Y, and Z' -- not just on the final Z'.

Because while X' *should* be similar to X, except with D and E's changes, hopefully non conflicting - sometimes there will be conflicts that are not detected by the merge, only by running tests.  Interferences.

I.e. sometimes X' will break tests, although X dos not, and although Z' does not either.

---

Of course, this only matters if your project takes the "All checkins should pass all tests" approach.  The approach that simplistic bisect uses.

It doesn't matter so much if you go back and retroactively label versions according to what tests have passed, etc.  (Which, of course, Mercurial cannot do worth a darn.)



No comments: