Subsequent runs of statsvn

Help
2011-06-08
2013-04-25
  • GavinBaumanis

    GavinBaumanis - 2011-06-08

    Hi there.
    I have been using the statsvn package recently and it works quite nicely.
    I have a few questions though that I am hoping that some seasoned users / devs might be able to shed some light on.

    I create the svn log as required.
    The, if I run the application, lets assume that it tells me that it is going to process 500 commits.
    I let the process run and I have my required stats - all is good.

    I do a a handful of changes.
    Re-create the svn log  and re-run the application again.
    It tells me that it is going to process 500 commits again.
    How can this be? - I would have assumed that it would only need to process the dozen commits that were performed after the last run?

    And lastly, just while I have your attention is there a "sweetspot" for settings?
    At the moment I am using 512MB of memory and 25 threads - and it seems to take quite a while.
    Can I bother you for some suggestions of values that I might try?

    Thanks in advance!
    Gavin.

     
  • Jason Kealey

    Jason Kealey - 2011-06-08

    > It tells me that it is going to process 500 commits again. How can this be?
    StatSVN caches previous queries in a file typically located in the .statsvn subfolder of your user's home directory. If you're seeing this behaviour, that file is either not getting saved (permission issues) or is later deleted. You may want to use the -cache-dir option to test this out.

    > And lastly, just while I have your attention is there a "sweetspot" for settings?
    I unfortunately don't have any suggestions for this.

    Hope this helps!

     
  • GavinBaumanis

    GavinBaumanis - 2011-06-08

    Thanks for the reply.
    The cache is certainly working, because we have 25,000 commits in this particular repository.
    If it wasn't - surely it would be trying to re-process them all?

    None the less I will try cache-dir option and let you know how that goes.

    As for it taking a long time, it isn't the processing of the diffs that takes a lot of time
    (Depending on the time between runs)

    it seems to be the creation of the html files that takes its sweet time.
    Last night for example, on my brand new i5 macbook pro (4 GB RAM) it took three hours from the last diff, to create the html files and return to the command prompt.

    That just "seems" to be a ridiculous amount of time, on a brand new machine.
    (In fact the first run on THIS machine took 18 hours)

    Anyway - thanks again - I will let you know how the cache-dir works out…

    Gavin.

     
  • GavinBaumanis

    GavinBaumanis - 2011-06-15

    Hi There,
    Here is an update;

    I am now running the package with the following script;
    sudo rm svn.log
    sudo svn log -xml -v > svn.log
    sudo java -jar -mx512m statsvn.jar -username myUsername -password myPassword -output-dir /Library/WebServer/Documents/statsvn -cache-dir /Library/WebServer/Documents/palcare/.statsvn/ -threads 25 ./svn.log ./

    The first time I ran it with the -cache-dir option it told me it was going to process 1500 changes.
    Which at least, was different from the 500ish I normally see.

    The directory shows that the cache file was updated at the last run time;
    -rw-r-r-   1 gavin  staff  24581683  15 Jun 10:53 cache_00d01e3f-8435-0410-80ea-eb2982af12ec.xml

    There have been 18 commits today (since the last run).
    A subsequent run of the script (above) states;

    Jun 15, 2011 4:55:17 PM net.sf.statsvn.util.JavaUtilTaskLogger info
    INFO: StatSVN - SVN statistics generation

    Parsing SVN log './svn.log'No exclude pattern
    svn diff 1/569 on r21438 (6092 ms.) main

    How are there possibly 569 commits to process when there have only been 18 since the last run?

    Am I missing something? / doing something wrong in the script, perhaps?
    Or is this expected behavior?
    And if it expected behavior - could someone please explain it to me!

    Thanks!
    Gavin

     
  • Jason Kealey

    Jason Kealey - 2011-06-15

    I think I now understand what is going on. Each of your 18 commits touches many files. In this case, an average of ~32 files. Therefore, we are performing 569 diffs, on 18 commits. I believe the most recent version of StatSVN only performs 18 'svn diff' commands as we can get all the diffs for one commit with one command, but the statistics engine knows it needs to perform 569 diffs.

    Hope this helps!

     
  • GavinBaumanis

    GavinBaumanis - 2011-06-15

    Thanks again for the reply.
    I appreciate the help.

    I re-ran the script directly after the last run.
    after hours - so no one has done any further work to the repository since the last run.

    28079439 15 Jun 20:29 cache_00d01e3f-8435-0410-80ea-eb2982af12ec.xml
    so the cache file was last edited at 8.30 pm.

    but statssvn still reports;
    Jun 15, 2011 9:41:14 PM net.sf.statsvn.util.JavaUtilTaskLogger info
    INFO: StatSVN - SVN statistics generation

    Parsing SVN log './svn.log'No exclude pattern
    svn diff 1/560 on r20909 (11520 ms.) main
    Scheduled 560 svn diff calls on 25 threads.

    Oddly the revision number in the follow-up run is less than than one before it.
    Can that be right?

    As always - thanks…
    Gavin

     
  • Jason Kealey

    Jason Kealey - 2011-06-15

    Did the first commit in the previous day contain 9 file changes? Starting to look like the cache file isn't properly persisted in your case, for some reason - unless you didn't specify the cache argument this time and it ran against the previous copy (which had already done one commit more than when you started here).

    All I can say is that some of it looks odd, but I won't be of much help finding out the core issue given the amount of info / time required to get to the root issue.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks