[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orion-dev] a story about "checkout by tag" and finding regressions
|
Because we don't have an automated bisect, the granularity of a build (tag) was much more manageable for me than pouring over a months worth of commits.
It also happened that once I saw the commits in the breaking build, I knew exactly what it was.
I think the main thing I appreciated so much about this feature is how easily we can now go back to an old build from Orion. (Granted, if you are on orion.eclipse.org, you have to hope that the client runs against the built server, but in my case, I could diagnose the problem even if there were parts that did not match.)
susan
![Inactive hide details for John Arthorne ---10/20/2011 05:58:47 AM---I think John J's point is that you don't need a tag to perf]()
John Arthorne ---10/20/2011 05:58:47 AM---I think John J's point is that you don't need a tag to perform a checkout. Once Susan had found the
From: John Arthorne <John_Arthorne@xxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 10/20/2011 05:58 AM
Subject: Re: [orion-dev] a story about "checkout by tag" and finding regressions
Sent by: orion-dev-bounces@xxxxxxxxxxx
I think John J's point is that you don't need a tag to perform a checkout. Once Susan had found the two tags between which the bug was introduced, she still had to figure out which commit that day caused the problem. If we had a "checkout" action in the log view, you could just bisect over the entire list of commits, whether they had a tag or not...
John A
Malgorzata Tomczyk <Malgorzata.Janczarska@xxxxxxxxxx>
Sent by: orion-dev-bounces@xxxxxxxxxxx
10/20/2011 05:22 AM
Please respond to
Orion developer discussions <orion-dev@xxxxxxxxxxx> |
|
To | Orion developer discussions <orion-dev@xxxxxxxxxxx> |
cc | ![]() |
Subject | Re: [orion-dev] a story about "checkout by tag" and finding regressions |
|
Because tags allow you to go back to particular build (on a particular
day). Susan could find *when* did the breaking change happen and then she
could find the exact commit that that was made that day and caused the
problem.
best regards,
Malgorzata Janczarska
Software Developer
IBM SWG Lab. Cracow. Poland
IBM Polska Sp. z o.o. oddział w Krakowie
ul. Armii Krajowej 18,
30-150 Kraków
NIP: 526-030-07-24
Sąd Rejonowy dla m.st. Warszawy, XII Wydział Gospodarczy KRS
KRS 0000012941, Kapitał Zakładowy: 33.000.000 PLN
From: John J Barton <johnjbarton@xxxxxxxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 2011-10-20 05:03
Subject: Re: [orion-dev] a story about "checkout by tag" and finding regressions
Sent by: orion-dev-bounces@xxxxxxxxxxx
Excuse my total ignorance, but I'd appreciate a quick explanation on why
the tag part makes this possible.
jjb
On Wed, Oct 19, 2011 at 4:15 PM, Susan Franklin McCourt <
susan_franklin@xxxxxxxxxx> wrote:
For those who don't know, Gosia/Tomek added "checkout by tag" support
in RC3. [1]
And for those who don't know, I have vowed to be a loyal self hoster,
and to never leave orion.eclipse.org for the command line, which
means that sometimes I have to do stupid things to get my work done,
in the name of discovering holes in our code. And so far, even the
stupidest workarounds haven't cost me too badly.
Anyway...here is a cool, albeit manual, scenario that I was able to
do today because of the "checkout by tag" support.
- I noticed a regression in the code [2]
- I wasn't sure where the code change had occurred, though I had
suspicions, and I was pretty sure I had caused it.
- I wanted to "git bisect" so that I could find exactly where the
behavior broke. But we don't have that yet, so...
- I looked at the list of tags for the org.eclipse.orion.client.core
repository and checked out the first build since I returned from
summer break.
- I always have a self hosting site running, so I refreshed the page
in that site to confirm that the code was working properly
- I visually "bisected" by checking out by tag a build halfway
between today and that day in the branch list, reloaded the page,
tested
- continued bisecting and retesting until I found where it broke
- it only took about 5 minutes to find the breakage, most of that
being reloading and testing the behavior (which you have to do
regardless of how you go about bisecting)
- having found the two builds, one good, the next bad, I just put a
breakpoint in my code on the self hosting site, and then could see a
good parameter coming in, and then a bad one. So I knew where things
had gone wrong
- At that point, I used git log to look at the commits in the two
branches, and from there I knew which change it was and quickly found
it. I suppose I could have rebased one branch on the other in order
to look at diffs (vs. git log), but since I was familiar with the
code I knew exactly which commit and file was causing the problem.
Cool!
susan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=360193
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=361481
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
