Inaccurate revision count for temporal period >= 2
famkedriessen opened this issue · comments
I ran the following command on testlogs 1 and 2 (in attachment), where 2 has an extra commit involving the file rest/pom.xml compared to 1.
java -jar code-maat-1.0.5-SNAPSHOT-standalone.jar -l logfiles\testnumber.log" -c git2 -a coupling --verbose-results -t 2 -n 1 -m 1 -i 1 -s 100 > changecoupling.csv
Note that I specify a temporal period to be 2 days. (For 1 day everything is correct, for 2+ days I see the same problem). In file 1, there are in this case two logical change sets (11.06+12.06;19.06+20.06), while in file 2 there are three: (11.06+12.06;18.06+19.06;19.06+20.06). I noticed that code-maat counts three revisions for rest/pom.xml in either case, which I think is incorrect behaviour (and which also influences the average-revs).
| entity | coupled | degree | average-revs | first-entity-revisions | second-entity-revisions | shared-revisions | testfile |
|---|---|---|---|---|---|---|---|
| graphql/.../ResolverConfig.java | rest/pom.xml | 80 | 3 | 2 | 3 | 2 | 1 |
| graphql/.../ResolverConfig.java | rest/pom.xml | 80 | 3 | 2 | 3 | 2 | 2 |
Yes, this is tricky but also expected. (see the original thread in #84).
The --temporal-period is implemented using a sliding window. That way, the same commit will be counted multiple times if there are commits on consecutive days.
FYI: I don't use the --temporal-period strategy myself: it becomes too noisy in terms of false positives. Instead I go for logical commit sets based on ticket/issue references.
Hi Adam, thanks for your reaction, makes sense. I do not have issue references to my disposal unfortunately, but I find that the temporal-window option is still useful to discover relevant couplings :)
I will close the issue now!