I have bisected Wine regressions several times in the last year following the cookbook in http://wiki.winehq.org/RegressionTesting. Those bisections were for the principal branch (or whatever you call it) of development. How do you do similar bisections for the branch of development from 1.6 to 1.6.1? I need the name of that branch of development and how you specify it to the bisect process. Sorry for the git newbie question, but following the above cookbook has been essentially my only git experience to date.
The reason I am asking about bisecting from 1.6 to 1.6.1 is I have recently found some fairly strong evidence that there is an important regression in behavior between 1.6-rc4 and 1.6.1. I have used Wine 1.6-rc4 with a lot of success as a test platform for MinGW/MSYS PLplot builds and tests, but when I recently tried 1.6.1, my usual parallel tests of PLplot software failed with an error indicating plot devices (small dll's) cannot be dynamically loaded by the PLplot principal library for that version of Wine. (The problem disappears if I do the tests sequentially for 1.6.1, but I obviously want to avoid that method of testing because it doubles the test time for my two-cpu PC.)
The tests of 1.6-rc4 and 1.6.1 were quite similar but not absolutely identical so I do have to confirm the regression in behaviour for 1.6.1 with absolutely identical tests. But assuming I can do that, then I still have to discover if the problem occurred for 1.6. If so, the bisection needs to be an ordinary principal branch one that I am already familiar with between 1.6-rc4 and 1.6, but if not it needs to follow the 1.6.x development branch between 1.6 an 1.6.1.
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On Jan 2, 2014, at 1:01 PM, Alan W. Irwin wrote:
I have bisected Wine regressions several times in the last year following the cookbook in http://wiki.winehq.org/RegressionTesting. Those bisections were for the principal branch (or whatever you call it) of development. How do you do similar bisections for the branch of development from 1.6 to 1.6.1? I need the name of that branch of development and how you specify it to the bisect process. Sorry for the git newbie question, but following the above cookbook has been essentially my only git experience to date.
The reason I am asking about bisecting from 1.6 to 1.6.1 is I have recently found some fairly strong evidence that there is an important regression in behavior between 1.6-rc4 and 1.6.1.
You can simply do "git bisect good wine-1.6-rc4" and "git bisect bad wine-1.6.1" or the equivalent. Git will traverse the commits between them. It doesn't need a branch name or anything like that.
Cheers, Ken
On 2014-01-02 13:07-0600 Ken Thomases wrote:
On Jan 2, 2014, at 1:01 PM, Alan W. Irwin wrote:
I have bisected Wine regressions several times in the last year following the cookbook in http://wiki.winehq.org/RegressionTesting. Those bisections were for the principal branch (or whatever you call it) of development. How do you do similar bisections for the branch of development from 1.6 to 1.6.1? I need the name of that branch of development and how you specify it to the bisect process. Sorry for the git newbie question, but following the above cookbook has been essentially my only git experience to date.
The reason I am asking about bisecting from 1.6 to 1.6.1 is I have recently found some fairly strong evidence that there is an important regression in behavior between 1.6-rc4 and 1.6.1.
You can simply do "git bisect good wine-1.6-rc4" and "git bisect bad wine-1.6.1" or the equivalent. Git will traverse the commits between them. It doesn't need a branch name or anything like that.
Thanks to you and André Hentschel for responding to my git question.
Just out of curiosity what would git do if you tried to do a bisect between 1.6.1 (for a case where that was "good") and the latest 1.7.x release (for a case where that was "bad"). There is obviously no direct forward development path between the two cases. Would git error out or would it automatically bisect using a development path consisting of the reverse development path back to 1.6 combined with the forward development path from there to the latest 1.7 release?
Although I am interested in the answer to the above question for future reference, it turns out I am not going to need to do a git bisect at the present time; I used bash.exe up-arrow to reconstruct the exact commands I used that generated the dynamic load errors before and put those commands in a script in preparation for a bisect. However,that script cannot reproduce the error and gives the same good test result for 1.6.1 that I got with 1.6-rc4 before! The good script result is for a fresh restart of wineconsole and bash.exe however, so I ascribe the previous dynamic load error results I observed with 1.6.1 to a stale wineconsole/bash.exe environment that had somehow been clobbered by previous commands I had done in that environment.
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________
On Fri, Jan 3, 2014 at 8:18 AM, Alan W. Irwin irwin@beluga.phys.uvic.ca wrote:
On 2014-01-02 13:07-0600 Ken Thomases wrote: Just out of curiosity what would git do if you tried to do a bisect between 1.6.1 (for a case where that was "good") and the latest 1.7.x release (for a case where that was "bad"). There is obviously no direct forward development path between the two cases. Would git error out or would it automatically bisect using a development path consisting of the reverse development path back to 1.6 combined with the forward development path from there to the latest 1.7 release?
It would find a common ancestor, and have you test thie (1.6 in this case (and warn you about this). e.g. in this case:
$ git bisect start $ git bisect bad master $ git bisect good wine-1.6.1
Bisecting: a merge base must be tested [50dc4cd636cc88031e0a49697ccc9f03b398e449] Release 1.6.
Am 02.01.2014 20:01, schrieb Alan W. Irwin:
I have bisected Wine regressions several times in the last year following the cookbook in http://wiki.winehq.org/RegressionTesting. Those bisections were for the principal branch (or whatever you call it) of development. How do you do similar bisections for the branch of development from 1.6 to 1.6.1? I need the name of that branch of development and how you specify it to the bisect process. Sorry for the git newbie question, but following the above cookbook has been essentially my only git experience to date.
The reason I am asking about bisecting from 1.6 to 1.6.1 is I have recently found some fairly strong evidence that there is an important regression in behavior between 1.6-rc4 and 1.6.1. I have used Wine 1.6-rc4 with a lot of success as a test platform for MinGW/MSYS PLplot builds and tests, but when I recently tried 1.6.1, my usual parallel tests of PLplot software failed with an error indicating plot devices (small dll's) cannot be dynamically loaded by the PLplot principal library for that version of Wine. (The problem disappears if I do the tests sequentially for 1.6.1, but I obviously want to avoid that method of testing because it doubles the test time for my two-cpu PC.)
git checkout origin/stable git branch stable git checkout stable
now you can move between branches with git checkout you can see them with git branch
-
Alan W. Irwin -
André Hentschel -
Frédéric Delanoy -
Ken Thomases