You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Adrian Robert <ar...@cogsci.ucsd.edu> on 2005/02/09 18:32:54 UTC
Fwd: [Issue 2206] RFE: Changed #/lines information in svn log -v
> http://subversion.tigris.org/issues/show_bug.cgi?id=2206
>
> ------- Additional comments from maxb@tigris.org Fri Jan 28 12:46:41
> -0800 2005 -------
> It could be done, yes. But, if we had an issue for every "it would be
> nice if
> ...", the issue tracker would be so bloated that we'd never find
> anything useful
> in it. If someone wants this, then they need to discuss it on the dev@
> list, and
> be prepared to write patches.
OK, thanks for at least taking a look at it. Although I phrased the
RFE as "it would be nice", I think the priority of it ought to be
relatively high since it is an existing CVS feature and an extremely
useful one at that. It was also discussed on the mailing list and
received at least some support there. I don't understand why there is
time to rewrite the entire back-end to please some whiners' complaints
that Berkeley DB is for some abstract, user-invisible reasons imperfect
but not to support a simple and useful CVS feature. But I give up.
We've used subversion for a year but will soon switch our project back
to CVS since log output is used every day whereas the branching
benefits of SVN are more rarely used in our case. We'll miss atomic
commits, but will continue to watch arch and other alternatives for the
next time we find the energy for a repository migration..
Thanks for your hard work on this open-source project nonetheless.
You can't please everybody, and I wouldn't expect you to try.
Adrian
On Jan 28, 2005, at 3:46 PM, maxb@tigris.org wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2206
>
>
>
> User maxb changed the following:
>
> What |Old value |New value
> =======================================================================
> =========
> Status|NEW |RESOLVED
> -----------------------------------------------------------------------
> ---------
> Resolution| |INVALID
> -----------------------------------------------------------------------
> ---------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 2206] RFE: Changed #/lines information in svn log -v
Posted by John Peacock <jp...@rowman.com>.
Adrian Robert wrote:
> It's a quick way to determine the rough magnitude of changes that went
> into a certain revision. This is useful in general for finding out the
> amount of work/change has gone into a file over various periods of time
> (helps you identify where extension / maintenance work is being focused
> in a project, can suggest places to refactor, etc.).
This topic has come up before and there were a number of people who
argued that this is a false metric (or at least a misleading one) for
most people. I don't want to minimize how _you_ perceive the utility of
this metric, but "lines changed" can be a very subjective measure. For
example, if I realize that a given block of code needs to be executed
only when a specific precondition is met, I can make a very small
change, basically two lines (the leading if() and the closing brace),
yet the number of lines changed could be huge because I changed the
whitespace to offset the enclosed code.
This is why a post-commit script (which could specifically ignore
whitespace only changes) may be much more appropriate than a possibly
difficult change to the core code.
As far as knowing which files have been touched more than others, it is
pretty easy to run a verbose log and run that through a script which
increments a counter for each time a given file is changed. It's not
exactly a "one-liner" for most people, but neither would it require much
in the way of sophistication to do it. At some point, Subversion should
have a better way of walking the repository to extract this kind of meta
data (perhaps when the mythical SQL backend emerges).
HTH
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 2206] RFE: Changed #/lines information in svn log -v
Posted by Adrian Robert <ar...@cogsci.ucsd.edu>.
On Feb 10, 2005, at 6:41 AM, Max Bowsher wrote:
> Adrian Robert wrote:
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=2206
>>>
>>> ------- Additional comments from maxb@tigris.org Fri Jan 28 12:46:41
>>> -0800 2005 -------
>>> It could be done, yes. But, if we had an issue for every "it would be
>>> nice if
>>> ...", the issue tracker would be so bloated that we'd never find
>>> anything useful
>>> in it. If someone wants this, then they need to discuss it on the
>>> dev@
>>> list, and
>>> be prepared to write patches.
>>
>> OK, thanks for at least taking a look at it. Although I phrased the
>> RFE as "it would be nice", I think the priority of it ought to be
>> relatively high since it is an existing CVS feature and an extremely
>> useful one at that.
>
> What do you find it useful for? It's not clear to me (or many others
> here) what it is useful for, other than statistics for statistics
> sake.
It's a quick way to determine the rough magnitude of changes that went
into a certain revision. This is useful in general for finding out the
amount of work/change has gone into a file over various periods of time
(helps you identify where extension / maintenance work is being focused
in a project, can suggest places to refactor, etc.). It also helps in
particular when you are trying to isolate a bug that popped up and want
to quickly determine which of a set of changed files in the date range
the bug emerged it would pay to examine first. It's a good utility as
well for detecting "botched commits", where a previous change was
undone, code was accidentally deleted and/or mis-pasted, etc..
At a more abstract level, the point of having logs is to provide a
higher-level overview of the changes in a repository than detailed
diffs. The +/- line number count supports this, in a complementary way
to the verbal log messages.
As for my other comments, I apologize for expressing my frustration in
an "unproductive" tone. Probably I am misinformed, through my own
negligence, on a number of points. Thanks for the suggestion of
writing a commit script, I'll look into it if I find the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 2206] RFE: Changed #/lines information in svn log -v
Posted by Kevin Puetz <pu...@puetzk.org>.
Max Bowsher wrote:
> Adrian Robert wrote:
<snip>
>> But I give up.
>> We've used subversion for a year but will soon switch our project back
>> to CVS since log output is used every day whereas the branching
>> benefits of SVN are more rarely used in our case. We'll miss atomic
>> commits,
> ...
>
> /me mutters something about cutting off your nose to spite your face.
>
> If LOC stats are so useful to you (and I *really* am curious to know why,
> because I genuinely don't understand), why not just write a post-commit
> script which runs "svn diff", calculates the stats, and then appends them
> to the log message?
>
> Max.
Indeed. Or even run diffstat and include that output, which would be an even
nicer view of the information (since the only use I can really see is the
'at a glance' feel for the scope and impact of the change).
It wouldn't even be that hard to use retroactively add them to the log
messages for the existing commits if desired... something like
for i in {1..407}; do
svnlook log -r $i svnroot/ > /tmp/log
svnlook diff -r $i svnroot/ | diffstat >> /tmp/log
svnadmin setlog svnroot -r $i /tmp/log
done;
Or use diffstat -f0 if you really want the hard numbers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 2206] RFE: Changed #/lines information in svn log -v
Posted by Max Bowsher <ma...@ukf.net>.
Adrian Robert wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2206
>>
>> ------- Additional comments from maxb@tigris.org Fri Jan 28 12:46:41
>> -0800 2005 -------
>> It could be done, yes. But, if we had an issue for every "it would be
>> nice if
>> ...", the issue tracker would be so bloated that we'd never find
>> anything useful
>> in it. If someone wants this, then they need to discuss it on the dev@
>> list, and
>> be prepared to write patches.
>
> OK, thanks for at least taking a look at it. Although I phrased the
> RFE as "it would be nice", I think the priority of it ought to be
> relatively high since it is an existing CVS feature and an extremely
> useful one at that.
What do you find it useful for? It's not clear to me (or many others here)
what it is useful for, other than statistics for statistics sake.
> It was also discussed on the mailing list and
> received at least some support there.
I do recall that it was discussed - IIRC, the support for it was luke-warm
at best.
> I don't understand why there is
> time to rewrite the entire back-end to please some whiners' complaints
> that Berkeley DB is for some abstract, user-invisible reasons imperfect
> but not to support a simple and useful CVS feature.
Oh *my*. What a sentence.
Since you don't seem to be much in the mood for productive discussion on
this point, I shall just inform you directly that utility of FSFS goes far
beyond satisfyin "some whiner's complaints".
Also, you appear to be severely confused about the open-source development
model. People created FSFS because they _wanted_ to, and volunarily donated
their time towards that goal. There's not some central arbiter doling out
programming assignments.
Furthermore, note that has not even been a consensus on these lists that
lines-of-code stats are "useful".
> But I give up.
> We've used subversion for a year but will soon switch our project back
> to CVS since log output is used every day whereas the branching
> benefits of SVN are more rarely used in our case. We'll miss atomic
> commits,
...
/me mutters something about cutting off your nose to spite your face.
If LOC stats are so useful to you (and I *really* am curious to know why,
because I genuinely don't understand), why not just write a post-commit
script which runs "svn diff", calculates the stats, and then appends them to
the log message?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org