No code stats

[nickpeirson]

I've got the plugin installed and I'm getting stats for tickets and wiki, however I'm getting no stats at all for code. Did I miss a step somewhere along the line?

I'm using Trac 0.12 with multiple repositories, with TracStats 0.3 (grabbed from github today).

I also spotted the following snippet in the readme:

In addition, an optional "project root" within your repository can be configured as the base for all projects and source code statistics::

[stats] root = path/to/projects

What form does the path take, eg url within trac, path on the file system, etc? How does this work with multiple repositories, as we have each of our projects in a separate repository?

[mrjbq7]

Do you use Git? If so you might need to enable caching of the repository with GitPlugin (e.g., set cached_repository = true and persistent_cache = true). You might also need to run "trac-admin repository resync" after making the configuration change.

See my most recent change to the README file for troubleshooting details.

Thanks!

[mrjbq7]

Oh, regarding your question about the project root, it currently is applied across all repositories that have been configured and was a change requested by someone that had a repository with a single directory at the top level containing sub-directories for each project.

I have a few pending changes for multiple repository support, it's not clear to me how everyone would like to see statistics (e.g., separate for each repository, or aggregated across all repositories). Do you have any suggestions?

[nickpeirson]

No Git, just the inbuilt svn integration, all using the direct-svnfs method. I tried resyncing in case that was the issue, but still nothing showing up.

We're set up with one svn repo per project, so the project root option isn't that interesting for us. Thinking about it, it might be interesting to use it just to report on our branches folder, as that's where the dev goes on rather than trunk or tags.

With regard to how we'd like to see stats across repos, we'll probably have a better idea when we're up and running with it, but my gut feeling is aggregated. I guess a solution that would provide both would be to aggregate it, then to be able to drill down by repo and path? Sounds like a lot more work though.

Let me know if there's any more info, logs, etc, I can provide to help diagnose this.

[mrjbq7]

If you are using SQLite backend, can you run this for me?

$ cd TRAC_HOME/db
$ sqlite3 trac.db "select count(*) from revision"
$ sqlite3 trac.db "select count(*) from node_change"
$ sqlite3 trac.db "select rev, repos from revision limit 10"

The source code statistics are generated by querying the project database, specifically the "revision" and "node_change" tables.

Also, try this:

$ python --version
$ trac-admin --version
$ cd TRAC_HOME/conf
$ grep repository_type trac.ini

And this:

$ trac-admin TRAC_HOME
Trac [TRAC_HOME]> repository resync *

Let me know if you see anything odd, or you can post some of the output and I can help.

Sorry, it's not working!

[nickpeirson]

Results from the sql. I'm thinking that this is where the problem is: $ sqlite3 trac.db "select count() from revision" 0 $ sqlite3 trac.db "select count() from node_change" 0 $ sqlite3 trac.db "select rev, repos from revision limit 10" $

Other test: $ python -V Python 2.4.3 $ trac-admin --version trac-admin 0.12 $ grep repository_type trac.ini repository_type = svn

The last line is not that useful, we're definitely using direct-svnfs rather than svn.

Resyncing:

repository resync * Resyncing repository history for b2c... 0 revisions cached. Resyncing repository history for prb... 0 revisions cached. Resyncing repository history for recycle_instore... 0 revisions cached. Resyncing repository history for tlib... 0 revisions cached. Done.

Looks like there's nothing being cached, although browsing SVN in trac is fine?

A quick googling turned up a comment on an unrelated issue that indicates there's no svn caching when using direct-svnfs:

To work around the problem I disabled caching for the Subversion repository by changing the repository type in the environment's trac.ini file from svn to direct-svnfs. This bypasses the generation of a CachedRepository? and directly uses SubversionRepository instead.

Does this mean we're out of luck for repo stats?

Thanks for taking the time to look into this.

[mrjbq7]

You might be out of luck with direct-svnfs. Is there a reason you don't run with just svn? I suspect if I were to add support for the same kind of code statistics queries with the direct-svnfs backend, I would need to build a caching layer to make it fast enough...

[nickpeirson]

Not particularly. I've had a look round for some documentation on the pros and cons of the different svn plugins, but couldn't find any. I've switched to svnfs, resynced and I'm now getting stats.

I did come across some talk about a caching layer for direct-svnfs, so sounds like it might possible implemented in trac at some point, but for now, one of the other svn plugins is the way to go.

Having seen the stats I do have one comment, but it's unrelated to this, so I'll raise it separately.

[xylo]

What about putting a note on the plugin page that direct-svnfs is not supported but svnfs is?