Re: [Statcvs-users] Questions & Thanks

[Richard C. <ri...@cy...>]

Robin,

Am 02.01.2005 um 18:45 schrieb Robin Getz:
> Also, when I was trying -cvsweb option, I passed it:
>  -cvsweb http://cvs.blackfin.uclinux.org/cgi-bin/cvsweb.cgi
>
> And statcvs passed me back urls formed like:
> http://cvs.blackfin.uclinux.org/cgi-bin/cvsweb.cgi/u-boot_1.1.1/cpu/ 
> bf533/interrupts.c.diff?r1=1.15&r2=1.16&f=h
>
> However, it needs to have a cvsroot= in it, like so:
> http://cvs.blackfin.uclinux.org/cgi-bin/cvsweb.cgi/u-boot_1.1.1/cpu/ 
> bf533/interrupts.c.diff?cvsroot=uboot533&r1=1.15&r2=1.16&f=h

This was recently fixed for ViewCVS. I just applied the same changes to  
the CVSWeb code. You have to add the ?cvsroot parameter to the -cvsweb  
URL, then the right URLs should be formed.

Can you check out the latest StatCVS from our CVS and compile and check  
if the URLs work now?


>> > 3) How are the user statistics -> modules -> pie chart created? What
>> > signifies when something should be kept together? or split apart?
>>
>> I'd have to look at the code to say for sure. If I remember correctly,
>> it works like this: By default, everything is kept separately. If all
>> of a directory's subdirectories taken together are less than some
>> threshold, then they will be lumped together. The intention was to
>> avoid lots of tiny pie slices, but it doesn't work very well, and a
>> case could be made for dropping these charts from the report
>> altogether.
>
> I actually think this is a great idea, but could be sorted by  
> sub-directory/file and things are added until they hit some threshold.  
> What happens on my logs is that 80% is grouped to "other".
>
> Check:
> http://statcvs.blackfin.uclinux.org/uboot533/user_lgsoft.html
> http://statcvs.blackfin.uclinux.org/gcc3/user_bernds.html

Yeah, that's why I said it doesn't work very well. Sounds like your  
approach might work better.

Again, could you submit a short RFE to the tracker so the idea doesn't  
get lost?


> We are doing a linux kernel port to the Blackfin processor, and our  
> log for the kernel cvs is 65Meg. Maybe some note about the -mx java  
> option in the doc would be nice?

I agree. Will do.


> I also noticed that while running on these large logs, it consumes  
> _very_ large amounts of CPU resources (while running, it takes 96-99%  
> of available CPU). Other than 'nice' any suggestions?

No, I'm sorry. StatCVS was not written with performance in mind, and  
probably never will be.

Cheers,
Richard