locAs you know, LavaBlast develops most of its applications using Microsoft technologies but we like to dabble with other technologies. We're behind the open source movement and have worked on a few open source projects, mainly in Java. One of these is StatSVN, a tool that retrieves information from a Subversion repository and generates various tables and charts describing the project development. It's so great even Eric Kemp used it on SubSonic. The tool uses StatCVS internally and I've recently been promoted to the project admin status on SourceForge (along with Benoit Xhenseval of Appendium). StatSVN has not evolved much in the last year, since the release of v0.3.1, but we've recently done a few enhancements.

Current improvements to both StatSVN and StatCVS

  • StatSVN: Faster diffs.
    • StatSVN now takes advantage of a new Subversion 1.4 feature which allows us to perform one svn diff per revision, instead of one svn diff per revision per file. If you don't have 1.4, the old behavior will continue to work.
    • The Apache project blocked our demo because we were doing too many svn diffs on their servers. Hopefully, this will solve this situation in addition to making everything faster.
    • You can still use the old mechanism by using the -force-legacy-diff command line option, should you encounter any problems with the new feature.
  • Both: Export to XML format.
    • A new -xml option generates XML files instead of the typical HTML reports.
  • Both: Now showing affected file count in a commit.
  • StatSVN: The revision number shows up on the commit page.
  • StatSVN: Added support for -tags-dir as a way to specify 'top' directory where the tags are stored, defaulted to "/tags/".
  • StatSVN: Added support for a -anonymize command line option, to anonymize committer names
  • ... and a few minor things.

 

*** Download the alpha version ***

We're looking for some outside help

Instead of releasing v0.4.0 prematurely, we'd like to ask you to help us out!

1) Beta testers and benchmarkers

Before going with a full blown release, we want to ensure that the new StatSVN diff works as intended in various contexts. It works on our repositories, but we'd like you to run it on yours. We want to ensure it works well regardless of the operating system, your language, the type of files in your repository, the number of revisions, etc. Ideally, you'd time the whole thing and let us know how much faster it is. Furthermore, if you're a real zealot, you'd compare the line counts computed by both algorithms to ensure they match. (The counts are cached in a local XML file... very easy to compare the results).

2) Minor bug fixing & improvements

We've basically fixed the issues that annoyed us personally, but there are some that remain in both the StatCVS tracker and the StatSVN tracker. You may also be interested in creating new reports, which you think would interest the community.

3) Cool enhancements / external projects.

StatCVS/StatSVN can now export XML. This enables you to create new applications that use the computed data... why not whip up a cool dynamic web application? As a demo, I've imported the XML in ASP.NET and used the Open Flash Chart control we've blogged about in the past.

pie

4) Up for a challenge?

Subversion supports move operations and CVS doesn't. While developing StatSVN, we decided we'd treat moves as a delete-add sequence, for simplicity's sake. However, this does generate inaccurate statistics. If you're in for a challenge, you could tackle this StatSVN enhancement. We prototyped something in the past, but it ended up being too slow for production use.

 

A few links

 

Conclusion

Even though StatSVN/StatCVS are Java-based and most of our readers operate in the .NET space, the application itself is platform independent. Personally, I enjoy loading up a recent version of Eclipse and working in Java once in a while because it helps me observe the best in both worlds. I much prefer coding in C# because of the easier string manipulation and the fact that everything is an object so you don't have to explicitly create an Integer object from your int to insert it into a collection. However, when working in VS.NET, I dearly miss the automatic incremental compilation feature that Eclipse runs when you save a file. 

kick it on DotNetKicks.com