 |
Web Development »
Applications & Tools »
Tools with source code
Intermediate
VssReporter 2.1 - A Visual SourceSafe reporting tool for build administratorsBy .dan.g.A support tool to allow those performing builds to independently determine exactly what source files have been changed and by whom |
VC6, VC7, VC7.1, .NET, Win2K, WinXP, Win2003, MFC, VS.NET2003, VS2005, Dev, QA
|
|
Advanced Search Add to IE Search |
|
|
|
||||||||||||||||
VssReporter requires Visual SourceSafe 5 or 6 to be pre-installed, both to run it and to build it.
Since this is not a free redistributable (as far as I am aware) I cannot include even the VSS component (ssapi.dll) that VssReporter requires.
Note: If anyone can point me to a Microsoft document that proves me wrong, then I will gladly include ssapi.dll - but not at the present.
With most real-world activities its fairly easy to determine whether someone has done something or not:
"Jimmy, have you cleaned your room?"
"Yes Dad"
(clump, clump, clump - sound of dad walking upstairs)
"No you jolly well haven't (or words to that effect). Get to it"
Software, however, is a completely different kettle of fish.
The bit you see (the binary's UI, web page or other) is generally just the tip of the iceberg (especially with binaries), with most of what really makes up the component hidden away out of sight.
Moreover, compiled binaries are further complicated by the extra level of indirection caused by the compilation process; something that becomes all too painfully clear to the unlucky sod responsible for performing regular builds on projects of more than one person.
It sounds so simple, mailing all the coders to find out what they've worked on since the last build. But that's when you discover that few coders retain a clear memory of exactly what they fixed (or broke) in the preceding week (or even day).
Indeed, some can barely remember what they had for breakfast ;)
It's the things we do almost unconsciously, like minor refactoring (aka 'spring cleaning' or 'tidying up'), that are especially prone to being forgotten.
I have had many experiences caused by both myself and others where an apparently innocuous 'minor' code change has caused no end of trouble because no one can recall changing anything in the code where the problem occurs.
Enter VssReporter!
At its simplest, VssReporter is a tool for querying SourceSafe to find out what source files have been changed after, before or between certain date(s).
Dates can be an explicit eg '02/08/2002' or the implicit eg a label.
It will allow you to query for modifications made by anyone, only yourself, or a named coder.
However, as handy as that may (or may not) sound, I've found that VssReporter's most significant value has been in the variety of problems to which I've been able to apply it.
Here are a few:
Regular Builds
As I mentioned before, being responsible for builds means you have to know exactly what has changed since the last build. Otherwise you can't possibly write appropriate release notes which means that the product you're building becomes increasingly undefined as time goes by.
Having been responsible for builds on a number of projects on which I also coded, I found VssReporter indispensible.
This is how I worked it:
I even caught myself out a few times when I discovered that I made some 'trivial' changes that I barely remembered making!
Restructuring Projects
Just recently I was required to make a number of small changes to a set of components ostensibly contained within a single Vss project root.
All personnel who had previously worked on these components had left the company and so I was delegated the task.
What I found when I tried to build the components was a real dog's breakfast:
"There's only one thing to do", I said to a co-worker, "re-structure the whole bloody thing!". To which he replied, "Well overdue".
That's when i hit a snag: how to determine what code really needed to be rebuilt since, in case you think this was a trivial exercise, I counted 47 projects stored below the root folder, all for 7 principal components.
First I spent an hour trying to figure it out the hard way, getting progressively more demoralized, until i couldn't stand it any more and went to whinge to Ed (my closest co-worker).
As i regaled him with the litany of short-sighted changes that had been made over the years, it occurred to me that all i needed was a way of determining what code had changed, say, over the last year as an indicator of what code was currently in use.
Two queries with VssReporter and a couple of hours later and the whole thing was done!
Snooping!
To my continued dismay as a programmer, I never cease to be amazed at how many of my co-workers will modify someone else's code simply because they can.
This is less my direct experience (I find people never modify my code more than once if you get my meaning), than observing a team of 4 guys working on a 3D engine a few years ago.
Every so often you would hear a scream because a fix someone had implemented had been 'unfixed' a few days later.
Similar problems occur with shared code libaries: a fix for one project can break another.
So every so often I now run VssReporter queries on certain projects to see if anything has changed - 'forewarned is forarmed' (or however it goes).
Using VssReporter is almost as trivial as installing it:
This will generate a list of files in the right-hand list control which, if you scroll the list to the right, also displays the last time the file was changed and the person who changed it.
Thereafter you can either copy the results to the clipboard as formatted text, or right-click on individual files and open SourceSafe on the parent project.
VssReporter manipulates VSS via the object model exported by the type library contained within ssapi.dll (does that sound right?).
Essentially its just a case of calling
#import "ssapi.dll" no_namespacein whatever files you want to access VSS's object model.
Then its a case of reading whatever documentation you can lay your mits on and carrying out lots of trial and error.
I think the core of the VSS code on VssReporter came from MSDN but if anyone thinks that there is credit due to anyone whose code I might have used then please tell me and I'll add a credit.
Because the VSS related bits of VssReporter are not that exciting, I thought I'd point out some other bits and pieces that you might find useful.
These are:
CVSSTreeCtrl::OnItemexpanding() in VSSTreeCtrl.cpp)
CVssreporterDlg::ReportOnItem() and CVssreporterDlg::Continue() in VSSReporterDlg.cpp)
CVssreporterDlg::OnInitDialog() in VSSReporterDlg.cpp)
CVssreporterDlg::OnCopytoclipboard() in VSSReporterDlg.cpp) The code is supplied here for you to use and abuse without restriction, except that you may not modify it and pass it off as your own.
General 
News 
Question 
Answer 
Joke 
Rant 
Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads.
|
PermaLink |
Privacy |
Terms of Use
Last Updated: 25 Mar 2006 Editor: Nishant Sivakumar |
Copyright 2003 by .dan.g. Everything else Copyright © CodeProject, 1999-2010 Web22 | Advertise on the Code Project |
In trying to automate our build process, I'm analyzing the Visual Build Pro product. They have referred me on for this particular task so here is what I'm attempting; please let me know if VssReporter can do this for me: