-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relate methods that changed between versions #98
Comments
@saledouble Could you confirm that we are identifying methods that changed in the new version (i.e., revision B)? |
In other words, we're not looking at the method in revision B. |
For example: class C {
void m() {
int a = 5;
}
} Revision B: class C {
void n() {
int a = 6;
}
} Please confirm that the changed method that is detected is |
What's interesting here is that you are analyzing the history but manipulating the current DOI. In other words, if you detect a method change in some version, that method may no longer be present. |
The DOI is only for elements in the current project. |
So, maybe we need actually two passes, one to construct a method rename refactoring graph, and then another pass to bump the DOI values. For example, if you detect that method In this graph, the nodes will be methods, i.e., every method in the history of the project, arcs with be rename refactorings. For example, if After the first pass, we will have this (rename) graph. Then, before the second pass, we should construct a hash table that tells us the current name of every method. In one pass, we will create (in O(n + a) time where n is the number of nodes and a the number of arcs) the table. Suppose m() winds up in the end as method
Even though |
Currently, the graph has already been built. Each vertex is composed of the method signature and the file path, which can uniquely locate the method. Each edge could represent method renaming or file renaming. Here is an example output to evaluate 20 commits (for saving time):
|
Hi @orenwf. This is the issue I discussed yesterday. There used to be a method called |
Currently, we only check body length of two methods. This is the caller. It always finds the most similar method from the candidate methods. For example, given a method in revision A, I get methods in revision B which have the same parameter numbers and types and then I find the most similar one from those candidate methods. |
|
Moved this into the future milestone. The idea is to make some progress without this and add it at some point afterwards. |
┆Issue is synchronized with this Asana task
The text was updated successfully, but these errors were encountered: