info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: query


From: Russ Sherk
Subject: Re: Re: query
Date: Sat, 18 Jun 2005 07:38:29 -0400

On 18 Jun 2005 03:07:42 -0000, Hridyesh Pant <address@hidden> wrote:
> 
> 
>  Hi,
>  I am able to get information about the files which are most frequently
> changing (descending order) between two dates. but now I need how much lines
> are added or removed from these files.
>  Hi Russ could you please guild me with the example how to get these
> information, it will be great.

the cvs log command gives this output:

        TAG_NNAME_5_3: 5.3
        TAG_NAME_INITIAL_REV: 1.1
keyword substitution: kv
total revisions: 18;    selected revisions: 18
description:
----------------------------
revision 5.14
date: 2005/04/28 16:35:54;  author: username;  state: Exp;  lines: +1 -6
My log message.
----------------------------

So all you have to do is parse the "lines: +x -y" part to get the #
lines added and/or removed.  Note: each field is separated by a
semi-colon and in the lines field: +x = added, -y = removed.

The log entries you must parse begin after the 'description:' line. 
Each entry starts with '----------------------------\nrevision '.  The
end of the log is
'============================================================================='

Remember, as Jim stated, this should not be used as an absolute
indicator of lines changed per file.

Cheers,

--Russ

>  
>  Thanks
>  Hridyesh 
>  
>  
>  
>  On Fri, 17 Jun 2005 Russ Sherk wrote :
>  >On 6/16/05, Jim Hyslop <address@hidden> wrote:
>  > > Russ Sherk wrote:
>  > > > On 6/16/05, Jim Hyslop <address@hidden> wrote:
>  > > >>I'm curious - what use could this information possibly be, anyway?
>  > > >
>  > > > Usually this information is used by managers to determine churn.
>  > > > Bigger churn (more files/lines changed) means bigger risk.
>  > >
>  > > Not if there's a proper set of unit tests in place.
>  > >
>  > > I'm always skeptical of raw numbers like this being used for any
>  > > meaningful analysis.
>  > >
>  > > I don't think simply counting the number of lines added or removed is a
>  > > good indication of risk. Suppose the tool reports "100 lines added, 100
>  > > lines removed." Does that mean one line was changed 100 times? 100
> lines
>  > > were changed, one time each? Changing one line 100 times carries less
>  > > risk than changing 100 lines once. And unless FishEye (or any other
>  > > software) performs a fairly complex analysis of exactly which lines
> were
>  > > added and removed, you won't know where on that spectrum your count of
>  > > "100 lines added/removed" lies.
>  >
>  >You are correct Jim.  It should be used together with other metrics to
>  >aid in determining the general health of a particular load or to see
>  >general trends.  E.g. we used to parse the logs between builds and
>  >generate a list of changed files grouped by log entry and PR #.  It
>  >provided a snapshot of the changes that was easy to scan.  (You could
>  >see what changed, how much changed etc.)  This was particularly useful
>  >for T&V.
>  >
>  >
>  > >
>  > > --
>  > > Jim
>  > >
>  > >
>  >
>  >Regards,
>  >
>  >--Russ
>  
> 
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]