You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our initial idea of implementing metrics(total lines of code and others) was to create a bucket of items containing analysis data of all the files available at a point of time, pick the latest change (in a file) and perform some sort of an aggregation.
For example, CoCom backend executed at a file level would produce results (ccn, loc, blanks, and others) for files affected in a commit, we decided to insert an item per file in the enrich index.
But it wouldn't be possible to visualize as bucketing would become complex and even in TimeLion(split) I couldn't find enough references fo our use case. This led us to think of the repository analysis (as a category for analyzer).
We could perform some metrics visualization with the help of the repository level analysis
(Ref.#11) except for evolution related.
The issue with repository-level analysis in case of implementing evolution metrics is that,
So for example, I have 129 files in my repository (today) and X commits were made today. This leads to the creation of 129 * X items in for a given time and this may lead to problems. such as
Information related to files affected in a commit are lost and hence a change cannot be tracked down to a file.
Memory issues.
The text was updated successfully, but these errors were encountered:
Context:
We could perform some metrics visualization with the help of the repository level analysis
(Ref.#11) except for evolution related.
The issue with repository-level analysis in case of implementing evolution metrics is that,
So for example, I have 129 files in my repository (today) and X commits were made today. This leads to the creation of 129 * X items in for a given time and this may lead to problems. such as
The text was updated successfully, but these errors were encountered: