Meaning of "churned methods" in repository.xml

10 views
Skip to first unread message

SJ

unread,
Aug 30, 2011, 1:17:20 PM8/30/11
to iBugs
Hi!

I wonder what the exact meaning of the "churned methods" entry in the
repository.xml files is.
First I thought this value tells me how many methods have been changed
during a bugfix.
But recently I took a closer look at bug 225831 of the Rhino
repository and noticed there is a discrepancy between the "churned
methods" value (which is 19 for this bug) and the actual number of
changed methods (which is 114).
Maybe 114 is not the exact number (due to the way I calculated it) but
I am quite sure much more than 19 methods have been changed during the
bugfix.
So what does the "churned methods" value in the .xml file tell me?

Best regards
SJ

Valentin Dallmeier

unread,
Sep 8, 2011, 6:06:11 AM9/8/11
to ib...@googlegroups.com
Hi SJ!

The value churned methods gives the number of methods changed by a fix ignoring methods where only whitespace or comments were changed. Does that make sense in our case?

Regards,

Valentin


--
You received this message because you are subscribed to the Google Groups "iBugs" group.
To post to this group, send email to ib...@googlegroups.com.
To unsubscribe from this group, send email to ibugs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ibugs?hl=en.


SJ

unread,
Sep 12, 2011, 5:42:01 AM9/12/11
to iBugs
Hi!

If I remember correctly, the software measures changed for most of
those methods. So I would assume there has been changed more than
that.
The next days I will take a closer look at the problem and post an
example.

Regards,
SJ

On 8 Sep., 12:06, Valentin Dallmeier <valentin.dallme...@gmail.com>
wrote:

SJ

unread,
Sep 17, 2011, 10:56:39 AM9/17/11
to iBugs
Hi again!

I found an easy example (not too big) where the discrepancy between
changed methods and the "churned methods" entry is clearly visible.
Please take a look at bug 137181 in rhino repository.
The only file mentioned in the repository.xml for this bug is "mozilla/
js/rhino/src/org/mozilla/javascript/Arguments.java".
The value of "methods-churned" is 1.

I made a diff on the Prefix/Postfix file and found the following:
The methods has(..), get(..), put(..) and delete(..) have been
changed. New return values, new if's etc. Not just whitespaces.
Additionally a new methods has been added called
sharedWithActivation(..).

As you can see 5 methods changed. So I am not sure what the "methods-
churned" value tries to tell me.

In this context the lecturer I am working for came up with quite an
important question:
Does the Prefix-Postfix difference contain changes in the code base
which are not part of the bugfix?
Or did you manage to isolate pure buigfix code in your repositories?

Best regards
SJ

Valentin Dallmeier

unread,
Sep 21, 2011, 10:49:41 AM9/21/11
to ib...@googlegroups.com
Hi!

I found an easy example (not too big) where the discrepancy between
changed methods and the "churned methods" entry is clearly visible.
Please take a look at bug 137181 in rhino repository.
The only file mentioned in the repository.xml for this bug is "mozilla/
js/rhino/src/org/mozilla/javascript/Arguments.java".
The value of "methods-churned" is 1.

I made a diff on the Prefix/Postfix file and found the following:
The methods has(..), get(..), put(..) and delete(..) have been
changed. New return values, new if's etc. Not just whitespaces.
Additionally a new methods has been added called
sharedWithActivation(..).

As you can see 5 methods changed. So I am not sure what the "methods-
churned" value tries to tell me.


Thank you for the report, I'll look into this but can't make any promises.

 
In this context the lecturer I am working for came up with quite an
important question:
Does the Prefix-Postfix difference contain changes in the code base
which are not part of the bugfix?
Or did you manage to isolate pure buigfix code in your repositories?


The data extraction is based on a heuristic that links commits to bugs. In my Phd thesis I've applied Delta Debugging to determine the set of relevant lines for a subset of all the fixes. The result is that in many cases there are lines that don't contribute to the fix. More on this is available in http://www.st.cs.uni-saarland.de/publications/details/dallmeier-phd-2010/ .

Regards,

Valentin

Reply all
Reply to author
Forward
0 new messages