Re: [LrdeTools] 406: Add detailed statistics for Olena 1.0.
On 2006-11-07, Roland Levillain <roland@lrde.epita.fr> wrote:
https://svn.lrde.epita.fr/svn/lrde-tools/trunk/build-farm
This script could be *much* better, an produce more significant results; for instance: - the total number of source lines of code of a given target, for the HEAD revision, and for previous revisions (graph). - likewise for a given committer and a given project; - the average patch size per committer, per project; - etc.
BTW, the script could avoid re-scanning the whole revisions of the inspected projects, and cache the results somewhere.
And we could use sloccount, too.
Suggestions, ideas and help welcome!
Yeah that's a good idea. Knowing the number of lines per commit etc would require a diff for each revision which sounds rather costly (especially if we're operating on remote repository such as https://svn.lrde.epita.fr/ instead of say file:///some/path/to/svn/repos). This would *certainly* require a caching mechanism. Another interesting idea would be to use svn blame on every file in the repos in order to know who "owns" how many lines of code in a given project/version. -- SIGOURE Benoit aka Tsuna (SUSv3 compliant) _____ "On a long enough timeline, the survival rate /EPITA\ Promo 2008.CSI/ACU for everyone drops to zero" -- Jack.
"T" == Tsuna <tsuna@warszawa.lrde.epita.fr> writes:
On 2006-11-07, Roland Levillain <roland@lrde.epita.fr> wrote:
https://svn.lrde.epita.fr/svn/lrde-tools/trunk/build-farm
This script could be *much* better, an produce more significant results; for instance: - the total number of source lines of code of a given target, for the HEAD revision, and for previous revisions (graph). - likewise for a given committer and a given project; - the average patch size per committer, per project; - etc.
BTW, the script could avoid re-scanning the whole revisions of the inspected projects, and cache the results somewhere.
And we could use sloccount, too.
Suggestions, ideas and help welcome!
Yeah that's a good idea. Knowing the number of lines per commit etc would require a diff for each revision which sounds rather costly (especially if we're operating on remote repository such as https://svn.lrde.epita.fr/ instead of say file:///some/path/to/svn/repos). This would *certainly* require a caching mechanism.
Another interesting idea would be to use svn blame on every file in the repos in order to know who "owns" how many lines of code in a given project/version.
It would be nice it this became a Trac plugin. That would make it world wild useful.
Akim Demaille <akim@lrde.epita.fr> writes:
"T" == Tsuna <tsuna@warszawa.lrde.epita.fr> writes:
On 2006-11-07, Roland Levillain <roland@lrde.epita.fr> wrote:
https://svn.lrde.epita.fr/svn/lrde-tools/trunk/build-farm
This script could be *much* better, an produce more significant results; for instance: - the total number of source lines of code of a given target, for the HEAD revision, and for previous revisions (graph). - likewise for a given committer and a given project; - the average patch size per committer, per project; - etc.
- the number of FIXME's throughout revisions ! :)
BTW, the script could avoid re-scanning the whole revisions of the inspected projects, and cache the results somewhere.
And we could use sloccount, too.
Suggestions, ideas and help welcome!
Yeah that's a good idea. Knowing the number of lines per commit etc would require a diff for each revision which sounds rather costly (especially if we're operating on remote repository such as https://svn.lrde.epita.fr/ instead of say file:///some/path/to/svn/repos). This would *certainly* require a caching mechanism.
Another interesting idea would be to use svn blame on every file in the repos in order to know who "owns" how many lines of code in a given project/version.
It would be nice it this became a Trac plugin. That would make it world wild useful.
You've read my mind. :) Maybe such a plugin already exists?
"Théo" == Thierry GERAUD <theo@lrde.epita.fr> writes:
Akim Demaille wrote:
... It would be nice it this became a Trac plugin. That would make it world wild useful.
in the world wild useful stuff we've already got "tiger"!
Arg, thanks, s/wild/wide/.
participants (4)
-
Akim Demaille -
Roland Levillain -
Thierry GERAUD -
Tsuna