Last week I was working with my project managers doing a retroactive analysis on project work in which we were left in a lurch by a developer who was leaving to take a new job. The question came up -- could we have had better insight into the risk when the reports we were getting in status meetings and on timesheets all pointed to good progress? I decided to take a look at Perforce reports, thinking that we should see a pattern of source code check-ins with timesheets and progress on assigned work. What follows is a quick review of what it takes to get reports out of Perforce from a management perspective if you need to watch development.
Perforce has a reporting toolkit for download off of their site, and I sensed that the Windows version was most established even though they have a Linux command line utility. I ran the installer, provided my account information, and connecting was pretty easy. I tinkered with the Linux and BSD utilities for a few minutes on Mac OS X, but no luck there, so off to Windows I went.
The toolkit gives you some Crystal runtime reports, but the date parameters don't seem to work and I was getting back comically huge "monthly" reports that went back to the beginning of time. The Crystal report output was rather basic, without good filtering or export capabilities, so I skipped past the lot of them and moved on to the ODBC driver.
The ODBC driver was the valuable thing in the mix, and I setup a quick connection to Excel and pulled in data from the CHANGES table. The basic trick here is to apply the p4options = 'longdesc' filter to the query, which will give you back all of the comments in the Description field.
For a brief time I toyed around with trying to get into the FILES table, wanting the details of all files checked in for a particular change, but for us the FILES table has over 1.6M records, and Perforce doesn't really support joins in the traditional way, so for now I'm focused on the information in the FILES table.
At the moment I'm pulling a report that sorts line items in the CHANGES table by USER (asc) and DATE (desc) going back a month or so. When compared to timesheet data, this gives us a bit more insight into the work being done on projects and whether or not team members are a) working on files with the right frequency, b) checking in code on a regular basis, and c) working on the right projects in Perforce.
I'll give the analysis about a month to see if this is a good way to track progress and assess risk. If it seems helpful, then I'll probably look at setting up a report in SQL Server Reporting Services and then publish out weekly and monthly reports to the management team.
Comments on reporting on Perforce are welcome.