A record of all check-ins for a project?

[GKoch]

I have been asked to get a tally of how many times changes have been made to files in a Flare project. So far as I can tell, the best way to do this would be to get a total of check-ins to Source Control from that project, after the project was created and initial topics added.

Problem: I can't find a way to do this. Source Control Explorer will give me a list of changesets to a specific Flare project, and opening a changeset will show the topics that were changed, but what I need is (most likely) a list of all occasions on which a topic was changed, along with dates. I don't see a way to create this in Analyzer either, or in Flare itself.

Help?

[RamonS]

Listing all commits will only list that (well, yea) and not all the changes. It can well be that ten changes were made and all of them were committed at the same time. Which source control system do you use? In VSTFS you can open the Source Control Explorer, right click on the project folder, and select View History from the context menu. That will give you all commits to that folder/project.
Out of curiosity, what is the benefit of knowing how many changes were made?

[GKoch]

We use Microsoft Visual Studio for source control. In my first post I was talking about doing what you describe-- checking the history of that folder. That only tells me the number of commits/changesets; not the number of topics.

We send review packages off to another department on a regular basis. That department makes changes to the topics in the review packages and sends them back, at which point we accept the changes or edit as needed. The goal is to have an idea not just of how many review packages have been processed in this way, but how many topics within those review packages had changes that needed to be reviewed.

Some review packages have one topic in them while others have hundreds, and not all of the topics will have changes in them each time the review package is sent back, so it's hard to have a good idea of how much has been done if you base it strictly on review package (which, for these purposes, is effectively the same as changeset).

[RamonS]

There is also a TFS Warehouse, basically the access to the TFS database. With that you could query for each changeset, get files included, grab the previous version, make a file compare, and then ultimately count the number of files that indeed did change per changeset.
Not sure if that is worth the effort for a somewhat unnecessary metric IMHO. Is the file count something to determine interdepartmental charges? Something to determine performance? Or just a stat that per month x number of files were processed?

[NorthEast]

Is it possible to work out from the TFS check-ins, which changes are from review comments and which are not?
Presumably you'd have to remember to add a comment to the check-in.

I've not used review packages, but when you get them back, could you use Flare to get the information on the number of changes?
e.g.
* You can generate a report showing Content Files > Files with Changes and Content Files > Files with Annotations.
* In Project Analysis, you can see Files with Changes and Files with Annotations (and you can export these to CSV to record/count them).

That would report the number of individual changes/annotations made - note there may be multiple per file.
That's slightly different to the count you'd get from TFS; since that's the total number of files you've changed, rather than the number of individual changes/annotations submitted.