> Charley said:
> <snip>,
> > If we had a second number specific to the file
> > ('file touches'), I'd use it, but it wouldn't be
> > the granularity I'd prefer: I'd want time also.
Shamim responded:
> I'm guessing you'd want it to behave just like the
> log function.
>
> Am I guessing correctly?? Thanks.
Yes, basically. It would be nice if there was an
option for 'roll-up' information, like merely
returning the number of touches to a file in a given
time range, instead of 'svn log myfile.c' and doing
some kind of 'line count' (or other extraction) to
determine the number of revisions.
I'm digging into the (C-language) client API now,
and haven't gotten very far, so perhaps this is
already there.
> Files wrote:
> > /me votes +1 for mimicking log-cmd.c and reporting
> > a count instead.
John Peacock responded:
> The point is not the revisions total. The point is
> to be able to determine frequency/stability.
>
> <snip>,
> For example, 10 changes in the course of the last
> year is a very different statement from 10 changes
> in the last day (or week or month). If, for
> example, you wanted to produce a velocity
> (changes/time period), it would denote something
> more useful, but it would still be a very imprecise
> measure.
I agree with John completely: changes/time is a
*much* more useful measure. Of course all measures
are imprecise, but the idea is metrics accumulation
to identify trends over many files, or over many time
periods for a given file. That's typically the point
of 'bug count' monitoring by module to determine
fitness-for-realease, and there's similarly high
correlation with these 'touches'.
The goal is to identify curves like:
F i l e 1 . c F i l e 2 . c
c | * c |
h | * h | * *
a | * a | * * * *
n | n | * * *
g | * g |
e | e |
s | * * * * s |
|--------------------- |--------------------
t i m e t i m e
Now, *that's* something to write home about, if the
subversion client API merely reported 'number of
revisions to a file' when given an explicit time
range (or revision range). (I'd merely call the API
multiple times to create the graph.)
If you want to 'go to town', then it would be
*fantastic* if the API reported 'number of touches'
AND the 'average/total number of lines touched' (to
be an indication of the average/total magnitude of
the changes in a time period. For example, ten
touches each changing one line isn't as dramatic as
ten touches each changing one hundred lines. Then,
my (bar range) graph would be:
F i l e 1 . c F i l e 2 . c
| I |
c | I I c | I I
h | I h | I I I I I I
a | I I a | I I I I I I I I
n | I n | I I I I
g | I g | I
e | I I I e |
s | I I I I s |
|--------------------- |--------------------
t i m e t i m e
Now I'm all excited. But, I must admit I'd put it in
the categories of:
"would be nice" (not required)
"high value" (desirable meta-data that's
generally expensive to extract
manually or post-hoc)
"occasionally used" (by most others, but I'd use it
frequently)
It's statistics like this, though, that can work their
way into the business process and become addictively
useful. It's possible this could become a uniquely
competitive feature in selecting Subversion over other
version control systems (it would be for me).
--charley
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 17:38:25 2003