Re: Detail Reporting tool for Subversion

>> Anyone know of a detail reporting tool for subversion ? Preferably
>> Open Source flavor ?
>>
>> We would like to get some stats on items like how many lines of code
>> were modified , how many times a file was modified, how many
>> checkouts/ins, who did the checkout/in etc.
>
> I'm curious what can actually be gained by attempting to measure these
> sorts of things.
>
> Shamelessly quoting myself from 2 weeks ago (July 28) when someone
> else asked about this:
>
> "Commits per developer is a really bad metric. If you're evaluating
> developers on the number of commits, you're just going to push them to
> perform more commits. Moreover, no two commits are "equal" - you could
> have one commit that touches half the files in your project that
> brings it crashing down, and then a second commit that changes one
> value in a config file which brings it back."
>
> But I prefer Karl Fogel's more succinct summary in that same thread:
>
> "Measure the quality of a programmer by the number of commits she
> makes is like measuring the quality of a legislature by the number of
> laws it passes."
>
> A more humorous take on it: http://thedailywtf.com/Articles/Productivity-20.aspx

To begin with, I agree with these statements. Blindly assuming that a
given metric is equivalent to a developer's productivity is asinine,
and the stuff of legend.

However, I think it's humorous that people are so quick to opine that
such metrics are worthless. Consider this: since you're on the
Subversion users mailing list, odds are that you know what you're
doing and that (if you write code) you're a reasonably productive
programmer. However, we all know that not everyone is so productive.

I was in a group last year that had several contracted employees (I
was an intern) whose productivity was hit-and-miss. It was hard for
the manager to keep tabs on everyone, and he had to double-check that
they were actually accomplishing what they claimed they were.
Obviously, even the coders who wrote lots of lines and committed
frequently had errors that needed to be corrected.

Statistics provided by StatSVN were just one piece of the puzzle. Say
what you will, but the graphs clearly demonstrated that certain people
were doing almost nothing in the repository. They contributed almost
no lines of code, committed extremely infrequently, etc. The point of
statistics is that they give you numbers which you can interpret
(hopefully intelligently) to help solve a problem. My boss was a smart
guy, and was able to better manage his deadlines when he had a better
idea of what was actually happening. By no means was reward based on
LOC or commits—he just knew where to keep an eye out. (Linking such
statistics with results from BuildBot or something similar can further
improve the results.)

The funny thing is that all the information that StatSVN provides is
cleaned from the SVN repository itself; it just puts it in forms that
are easier to interpret. For example, I wouldn't want to scan through
logs to see what authors' commit patterns are like, or add up how many
lines changed, or try to figure out if people are working on the
modules they're assigned to. Stats are not infallible, but they're
also not useless. In commercial development situations, metrics such
as these are more important than when developing OSS, like it or not.

My 2˘,
   - Quinn